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(54) Methods and apparatus for storage and retrieval of name space information in a distributed 
computing system 



(57) A distributed computing environment is dis- 
closed which allows a user at one location to access re- 
sources at other locations. Each resource in the distrib- 
uted computing environment is represented as a hierar- 
chical file system A user or process has a name space 
comprised of at least one hierarchical file system pro- 
vided by a connected resource. The distributed comput- 
ing environment allows a first processor to invoke exe- 
cution of a processing task by a remote processor. The 
first processor transmits a representation of its current 
name space to the remote processor. The remote proc- 



essor will execute the processing task on a name space 
modified in accordance with the name space represen- 
tation received from the first processor. The transmitted 
representation of the name space associated with the 
first processor includes at least one dynamic name 
space modification command, such as those executed 
by a user after logging into the distributed computing 
system. A plurality of data structures are provided for 
storing path information which allows the pathname of 
a given channel, which represents a file, to be deter- 
mined. The stored path information allows the hierarchi- 
cal file tree of a connected file system to be generated. 
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Description 

FIELD OF THE INVENTION 

The present invention relates to a distributed com- 
puting system, and more particularly, to methods and 
apparatus for storage and retrieval of name space infor- 
mation in a distributed computing system. 

BACKGROUND OF THE INVENTION 

The resources and computation tasks in a comput- 
ing system are increasingly being spread among a plu- 
rality of network nodes to form distributed computing 
systems. The increased popularity of distributed com- 
puting systems is due in large part to the increased cost 
efficiency and availability that they provide. When cen- 
tralized resources are shared by a plurality of users in 
a distributed system, their costs are distributed over a 
larger user base. In addition, the centralization of shared 
resources makes the administration and maintenance 
of these resources more efficient and also potentially 
more reliable due to the possibility of a centralized back- 
up mechanism. Furthermore, the redundancy provided 
by most distributed computing environments improves 
the ability to recover from a failure by allowing process- 
ing to continue on an alternate device upon a detected 
failure. 

A distributed system offers improvements in 
processing times as well For example, a particular 
processing task can be partitioned in a distributed sys- 
tem into a number of smaller tasks to be executed con- 
currently on a plurality of distributed processors. In ad- 
dition, the processing time of a single processing task 
can often be improved by exporting the task to a more 
powerful centralized processor. 

For a distributed computing system to succeed, 
however, a user must be able to access the diverse and 
distributed resources in a uniform manner. Thus, the 
physical location of any given resource and the peculiar 
details of its protocols must be transparent to a user. In 
a number of distributed computing environments, such 
as the Plan 9 distributed processing system, developed 
by AT&T Bell Laboratories, every resource in the system 
is implemented as a hierarchical -file" system, com- 
prised of a tree of the file-like objects that are provided 
by the resource. Thus, the diverse resources in the dis- 
tributed system can be accessed in a uniform, file-ori- 
ented manner, even if the resource being accessed is 
not a file in the traditional sense. 

Typically, the operating system in such a distributed 
computing environment allows each "file" to have an al- 
phanumeric name associated with it, which may be uti- 
lized to access the file in the name space. In addition, 
the relationship between files may be specified, thereby 
allowing files to be organized into the hierarchical tree 
of directories and files. A file is typically identified in the 
name space by a pathname through the hierarchical 



structure to the given file. For a general discussion of 
name spaces in distributed computing environments, 
see Roger M. Needham, Names, in Distributed Systems 
315-27 (Sape Mullender ed., 2d ed. 1993). 
5 The representation of each resource in a distributed 
system as a set of files provides the desired transpar- 
ency and allows each user or process to assemble a 
private view of the set of available resources. Thus, 
each user or process can have a customized name 
10 space comprised of the file trees provided by one or 
more selected resources. Thereafter, when a user or 
process implements an operation on a file, identified by 
the pathname through the customized hierarchical file 
tree, the pathname is resolved to the particular file-like 
15 object that should be operated upon. 

While the local operating system kernel can keep 
track of the relationship between names and physical 
objects in the customized name space of a local user or 
process, name space resolution problems are invited 
when the user or process exports a processing task to 
another, perhaps more powerful, remote processor in 
the distributed system. If the remote processor does not 
perform the particular processing task on the exact 
same name space assembled by the exporting user or 
process, then a pathname may not be correctly trans- 
lated into the appropriate file-like object to be operated 
upon. 

As is apparent from the above discussion, a need 
exists for a distributed computing environment which al- 
lows a first processor to invoke execution of a process- 
ing task by a remote processor, where the remote proc- 
essor will execute the processing task on a name space 
modified in accordance with a name space representa- 
tion received from the first processor. A further need ex- 
ists for an apparatus for storing name space information 
in a node of the distributed computing system, where 
the stored name space information includes an indica- 
tion of the hierarchical file systems provided by resourc- 
es which have been joined to an indicated portion of the 
name space, as well as path information which allows 
the file system hierarchy of each connected resource to 
be recreated. A further need exists for a method for iden- 
tifying a pathname associated with a given channel, 
which represents a file, in the distributed computing sys- 
tem. 

SUMMARY OF THE INVENTION 

Generally, according to one aspect of the invention, 
a computing environment distributed across a plurality 
of computers and networks is provided which allows a 
user at one location to access resources at other loca- 
tions. The distributed computing environment allows a 
first processor to invoke execution of a processing task 
by a remote processor, such as a central processing 
unit. According to features of the present invention, the 
first processor will transmit a representation of its cur- 
rent name space to the remote processor. The remote 
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processor will execute the processing task on a name 
space modified in accordance with the name space rep- 
resentation received from the first processor. 

One feature of the present invention provides a 
method performed by the first processor in the distrib- 5 
uted computing system for invoking execution of a 
processing task on the remote processor, where the first 
processor has an associated first name space formed 
by a plurality of name space modification commands. 
The method comprises the steps of: establishing a com- 
munication link between the first processor and the re- 
mote processor; identifying the plurality of name space 
modification commands that form the first name space, 
where the plurality of identified name space modification 
commands includes at least one dynamic name space 
modification command; and transmitting the plurality of 
name space modification commands to the remote 
processor for execution of the processing task by the 
remote processor on a name space modified in accord- 
ance with the transmitted plurality of name space mod- 
ification commands. 

A further feature of the invention provides a method 
performed by the remote processor in the distributed 
computing system for executing a processing task re- 
ceived from the first processor, where the first processor 
has a first name space formed by a plurality of name 
space modification commands, and the remote proces- 
sor has a second name space. The method comprises 
the steps of: 

processing a connection request from the first proces- 
sor; allocating a process on the remote processor to ex- 
ecute the invoked processing task; receiving from the 
first processor the plurality of name space modification 
commands that form the first name space, where the 
plurality of received name space modification com- 
mands includes at least one dynamic name space mod- 
ification command; establishing a communication link to 
the first processor; mounting the communication link to 
the first processor in a predefined place in the second 
name space; executing the plurality of received name 
space modification commands to modify the second 
name space; and executing the invoked processing task 
on the modified second name space. 

A further feature of the invention provides an appa- 
ratus for storing name space information in a node of 
the distributed computing system, where each of the re- 
sources is represented as a hierarchical file system, the 
name space is comprised of at least one resource hier- 
archical file system joined to the name space by one or 
more name space modification commands and the 
name space is modifiable on a per process basis. The 
apparatus comprises: a mount table for storing an indi- 
cation of each of the resource hierarchical file systems 
joined to an indicated portion of the name space by the 
name space modification commands; and a server tree 
path table associated with each of the hierarchical file 
systems joined to the name space. The server tree path 
table provides path information for each of the files in 



the associated hierarchical file system, with the path in- 
formation allowing the file system hierarchy to be recre- 
ated. The path information stored for each of the files 
includes the name of the associated file and an indica- 
tion of the parent file of the associated file in the name 
space hierarchy. 

A further feature of the invention provides a method 
for identifying a pathname associated with a given chan- 
nel in the distributed computing system, where the dis- 
tributed computing system includes a plurality of distrib- 
uted resources, each of the resources are represented 
as a hierarchical file system comprised of one or more 
files, a collection of one or more hierarchical file systems 
forms a name space, each of the hierarchical file sys- 
tems has a root directory, each of the channels repre- 
sents a given file in the name space, each of the files 
has a filename comprised of an alphanumeric label, and 
the pathname identifies the file by specifying a path 
through the hierarchical file system from the root direc- 
tory to the given file. The method comprises the steps of : 
associating a path data structure with each of the chan- 
nels, where the path data structure stores the filename 
of the associated file and a pointer to the path data struc- 
ture associated with a parent file in the name space hi- 
erarchy; receiving an indication of the channel for which 
the pathname is to be identified; identifying the path data 
structure associated with the indicated channel; retriev- 
ing the filename and the pointer to the path data struc- 
ture associated with the parent file from the identified 
path data structure; and following the retrieved pointer 
to the path data structure associated with the parent file 
and repeating the previous retrieval step until the root 
directory of the hierarchical file system is reached, 
where each of the filenames retrieved from the path data 
structures are appended to the front of the generated 
pathname associated with the indicated channel. 

A more complete understanding of the present in- 
vention, as well as further features and advantages of 
the invention, will be obtained by reference to the de- 
tailed description and drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 illustrates a distributed computing environ- 
ment, suitable for implementing features of the 
present invention; 

FIG. 2A illustrates an isometric view of a general 
purpose computing system which may serve as a 
user terminal in the distributed computing environ- 
ment of FIG. 1; 

FIG. 2B illustrates a block diagram of a micro- 
processing system, which may be utilized in con- 
junction with the general purpose computing sys- 
tem of FIG. 2A; 

FIG. 3A illustrates the individual name spaces of a 
user terminal and two file servers; 
FIG. 3B illustrates the customized name space of 
the user of FIG. 3A, comprised of the file trees of 
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the two file servers; 

FIG. 4 A illustrates an operating system kernel 
which incorporates features of the present inven- 
tion; 

FIG. 4B illustrates a device table, suitable for use $ 
by the kernel of FIG. 4A to store an array of pointers 
to device-specific procedure calls; 
FIG. 4C illustrates a mount device, suitable for use 
by the kernel of FIG. 4A as an interface to the de- 
vices in the distributed computing environment of 10 
FIG. 1 not implemented by the kernel; 
FIG. 5 illustrates a partial view of a process data 
structure and a file descriptor array, suitable for stor- 
ing file access information for a particular process; 
FIG. 6 illustrates a channel data structure, utilized is 
by the kernel of FIG. 4A to represent a particular 
file, and to store information related to the file; 
FIG. 7 illustrates a plurality of related data struc- 
tures, which together form the mount point of FIG. 
4C to a particular non-kernel file system, 20 
FIG. 8A illustrates a mount table and associated da- 
ta structures suitable for storing the sequence of 
bind and mount commands that form the name 
space of a user or process; 

FIG. 8B illustrates a mount "from" data structure 25 
and at least one mount Mo" data structure, which 
together form an entry in the mount table of FIG. 8A; 
FIG. 9A illustrates a network database, suitable for 
storing network destination address information for 
a plurality of machines in the distributed computing 30 
environment of FIG. 1; 

FIG. 9B illustrates a portion of the name space of a 

user or process related to networks; 

FIG. 10 illustrates a directory in the name space of 

a user or process, suitable for storing a file for each 35 

communication link to the non-kernel file systems 

shown in FIG. 4C; 

FIG. 1 1 A illustrates a server tree path table, suitable 
for storing path information for each of the files in 
the tree of a non-kernel file system shown in FIG. 40 

4C; 

FIG. 11 B illustrates a server tree path list, suitable 
for storing pointers to path data structures for each 
file in the tree of a non-kernel file system shown in 
FIG. 4C; 45 
FIG. 11 C illustrates a path data structure, suitable 
for storing path information for a particular file; 
FIGS. 12A and 12B, collectively, are a flow chart 
describing a pathname-to-channel convertor which 
may be utilized to translate a given pathname into so 
the appropriate file-like object, represented as a 
channel, to be operated upon; 
FIG. 13 is a flow chart describing a walk function 
which may be utilized to move from one level of a 
file tree to another; 55 
FIG. 1 4 is a flow chart describing a device walk sub- 
routine which may be utilized by the walk function 
of FIG 1 3 to search the directory of a given device 



for a particular file; 

FIG. 15 is a flow chart describing a domount func- 
tion which may be utilized to access the mount table 
of FIG. 8A to determine whether a particular chan- 
nel has been mounted upon, and if so, perform the 
necessary channel substitution; 
FIG. 16A is a flow chart describing a process exe- 
cution exporter which may be utilized to export a 
processing task to a remote processor, together 
with an accurate representation of the name space 
of the exporting user or process; 
FIG. 16B is a flow chart describing a process exe- 
cution importer which cooperates with the process 
execution exporter of FIG. 16A to import the 
processing task and to regenerate the name space 
of the exporting user or process; 
FIG. 17 is a flow chart describing a read name 
space subroutine which may be utilized by the proc- 
ess execution exporter of FIG. 16A to access the 
mount table of FIG. 8A to generate the list of bind 
and mount commands that form the name space of 
the exporting user or process; 
FIG. 18 is a flow chart describing a pathname sub- 
stitution subroutine which may be utilized by the 
process execution exporter of FIG. 16A to analyze 
the list of bind and mount commands generated by 
the read name space subroutine of FIG. 17 and to 
replace the pathnames in the name space of the 
server that provides the file with the complete 
pathnames in the overall name space of the export- 
ing user or process; 

FIGS. 1 9A through 1 9C, collectively, are a flow chart 
describing a package name space subroutine which 
may be utilized by the process execution exporter 
of FIG. 16Ato package the list of bind and mount 
commands modified by the pathname substitution 
subroutine of FIG. 1 8 for transmission to the remote 
processor; and 

FIG. 20 is a flow chart describing a channel-to- 
pathname convertor which may be utilized by the 
read name space subroutine of FIG. 17 to replace 
a channel representing a file with the corresponding 
pathname of the file. 

DETAILED DESCRIPTION 

FIG. 1 shows an illustrative configuration for a dis- 
tributed computing environment 100, suitable for imple- 
menting features of the present invention. As discussed 
further below, the distributed computing environment 
100 is preferably distributed across a plurality of com- 
puters and networks, and allows a user at one location 
to access resources at other locations, for example, by 
establishing a communication link between the user's 
terminal and the desired resource. 

The distributed computing environment 100 allows 
a processing task to be exported to a remote processor 
According to one feature of the present invention, when 
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a user or process indicates that a processing task 
should be exported to a remote process, the current 
state of the name space associated with the exporting 
user or process will be evaluated. Thereafter, the current 
state of the name space, in other words, the sequence 
of name space modifications commands which have 
been executed by the user or process to form the name 
space, are transmitted to the remote processor. In this 
manner, the remote processor can accurately recreate 
the name space of the exporting user or process and 
thereby reliably resolve a file name into the appropriate 
file or file-like object that should be operated on. 

The invention will be described in eight main sec- 
tions as follows. First, the overall network environment, 
as well as an illustrative node of the distributed network 
100 will initially be described relative to FIGS. 1 and 2 
in a section entitled SYSTEM ARCHITECTURE. Sec- 
ond, the name space associated with a user or a proc- 
ess in the distributed computing system is described in 
a section entitled CONCEPTUAL REPRESENTATION 
OF RESOURCES IN A NAME SPACE. This section in- 
cludes a discussion of the manner in which the hierar- 
chical file trees of one or more remote resources may 
be joined into the desired location of the customized 
name space of a particular user or process. 

Third, a preferred operating system incorporating 
features of the present invention is discussed in a sec- 
tion entitled OPERATING SYSTEM KERNEL This sec- 
tion includes a discussion of the interface provided by 
the operating system kernel to every resource in the dis- 
tributed computing environment. Fourth, a preferred im- 
plementation for representing the individual file-like ob- 
jects that may be accessed in the name space will be 
described in a section entitled ACCESSING RE- 
SOURCES IN THE DISTRIBUTED SYSTEM. A pre- 
ferred embodiment of a channel data structure, which 
preferably represents each file that may be accessed, 
is discussed in conjunction with FIG. 6. In addition, fur- 
ther data structures that are utilized by the kernel to 
store file-access information are discussed relative to 
FIG. 5. 

Fifth, the data structures and communication links 
that are established by the kernel to communicate with 
a resource that is not provided by the kernel are dis- 
cussed in a section entitled COMMUNICATING WITH 
NON-KERNEL FILE SYSTEMS. This section describes 
the establishment of a communication link, such as a 
pipe or a network connection, to a desired non-kernel 
file system the creation of the appropriate data struc- 
tures for storing access and path information for the non- 
kernel file system; and the manner in which the root di- 
rectory of the file tree of the non-kernel file system is 
mounted into the name space of the local user or proc- 
ess. In addition, a preferred implementation of a mount 
table 800 for storing the series of name space modifica- 
tion commands that form the current state of the local 
name space is discussed in conjunction with FIGS. 8A 
and 8B 



Sixth, a preferred implementation for creating and 
managing network connections is discussed in a section 
entitled NETWORK REPRESENTATION. This section 
includes a discussion of translating between symbolic 

s machine names and the associated network destination 
addresses. Seventh, a number of preferred path data 
structures incorporating features of the present inven- 
tion are discussed in a section entitled NAME SPACE 
INFORMATION DATA STRUCTURES. This section de- 

10 scribes how the pathname associated with a particular 
channel can be determined and how the name space of 
the accessed files in the file tree of each connected non- 
kernel file system may be recreated. 

Finally, processes incorporating features of the 

15 present invention are described in a section entitled 
NAME SPACE PROCESSES. This section includes de- 
scribes a process execution exporter 1600, discussed 
in conjunction with FIG. 16A, which may be utilized to 
export a processing task, together with an accurate rep- 

20 resentation of the current state of the local name space, 
to a remote processor. In addition, a process execution 
importer 1650, discussed in conjunction with FIG. 16B, 
may be executed by the selected remote processor to 
import the processing task exported by the local node. 

2S The process execution importer 1650 recreates the 
name space of the local node, and thereby ensures that 
filenames are accurately resolved into the appropriate 
files or file-like objects to be operated on. 

The distributed computing environment 100 shown 

30 in FIG. 1 is preferably embodied as a Plan 9 distributed 
processing system, developed by AT&T Bell Laborato- 
ries, 600 Mountain Avenue, Murray Hill, New Jersey 
07974-0636, as modified herein to provide mechanisms 
for storing and retrieving name space information. For 

35 a detailed discussion of the Plan 9 distributed process- 
ing system, see U.S. Patent Application Serial Number 
08/237,967, filed May 3, 1994, which is a continuation 
of U.S. Patent Application Serial Number 07/702,651, 
filed May 17, 1991, now abandoned, and U.S. Patent 

40 Application Serial Number 08/247,626, filed May 20, 
1 994, which is a continuation of U.S. Patent Application 
Serial Number 07/999,755, filed December 31, 1992, 
now abandoned, each incorporated herein by refer- 
ence. Additional discussions of the Plan 9 distributed 

45 processing system may be found in David Presotto et 
al., "Plan 9, A Distributed System," Proc. of the Spring 
1991 EurOpen Conference, pp. 43-50 (Tromso, Norway 
1991); and "Plan 9 from Bell Labs, Programmers Man- 
ual", each of which are incorporated herein by reference 

so and are available by file transfer protocol (ftp) from the 
internet address plan9.att.com in the directories pub/ 
plan9doc and pub/plan9dist. 

SYSTEM ARCHITECTURE 

55 

Generally, the distributed computing environment 
100 includes a plurality of user terminals, such as the 
terminals 105-110, as well as one or more central 
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processing unit (cpu) servers 1 20-1 21 , and one or more 
file servers 130-131. The user terminals 105-110 may 
be embodied, for example, as a general-purpose com- 
puting system 200, discussed further below in conjunc- 
tion with FIGS. 2A and 2B, such as a minicomputer, a 
work station, or a personal computer. As discussed fur- 
ther below, the user terminals 105-110 preferably pro- 
vide each user of the distributed computing environment 
100 with a dedicated computer having a bit map screen 
and a mouse on which to run a window system. The win- 
dow system provides a multiplexed interface to the re- 
sources in the distributed computing environment 100. 

The cpu servers 120-121 preferably concentrate 
computing power into large multiprocessors in a known 
manner and may be embodied, for example, as a Power 
Series machine, commercially available from Silicon 
Graphics. Thus, for computationally intensive tasks, 
such as compilation, the user can execute a cpu com- 
mand, discussed further below in conjunction with FIG. 
16A, which will transfer the processing of subsequent 
commands to a cpu server, such as the cpu 1 20 or 1 21 . 
Although a prompt from the command interpreter will ap- 
pear in the active window of the user's terminal 105-110 
following execution of the cpu command, the command 
interpreter will be running on the cpu server 1 20 or 1 21 . 

As discussed below, the present invention allows 
the processing tasks that are performed by the remote 
cpu server 1 20 or 1 21 to be performed in a name space 
that is identical to the name space of the user or process 
executing on the terminal. Name spaces are discussed 
below in a section entitled CONCEPTUAL REPRESEN- 
TATION OF RESOURCES IN A NAME SPACE. 

The file servers 130-131 provide repositories for 
storage of files utilized by the user terminals 105-110, 
as well as by the cpu servers 1 20-1 21 , in a known man- 
ner. As discussed further below in conjunction with 
FIGS. 3A and 3B, the file servers 130-131 provide a hi- 
erarchical file system, comprised of a tree of files pro- 
vided by the server 1 30-1 31 . 

The organization and management of networks is 
an important aspect of any distributed system, such as 
the distributed computing environment 100 shown in 
FIG. 1 . This is especially true where key components of 
the distributed computing environment 1 00, such as the 
cpu servers 120-121 and the file servers 130-131 are 
positioned at centralized locations. In a preferred em- 
bodiment, the cpu servers 120-121 and the file servers 
1 30-1 31 are interconnected by high-speed network con- 
nections, such as high bandwidth point-to-point fiber 
links. The user terminals 105-110, however, may be 
connected to other resources in the distributed comput- 
ing environment 100 by lower-speed network connec- 
tions 1 50, such as Ethernet or Datakit connections. One 
suitable implementation for creating and managing net- 
work connections is discussed further below in conjunc- 
tion with FIGS. 9A and 9B. 

One embodiment of a general-purpose computing 
system 200, suitable for use as a user terminal 105-110 



is shown in further detail in FIG. 2A. The general-pur- 
pose computing system 200 may be, for example, a min- 
icomputer, a work station, or a personal computer. The 
general purpose computing system 200 preferably in- 

s eludes a display monitor 204, one or more processing 
units 206, a memory storage device 207, such as a ran- 
dom access memory, busses 224 and one or more user 
interfaces, such as a mouse 208 and a keyboard 205. 
As indicated above, the display monitor 204 preferably 

10 supports a window system. The processing unit 206 and 
memory storage device 207 are discussed further below 
in conjunction with FIG. 2B. 

The computing system 200 may also include an ex- 
ternal disk drive 202 and a hard disk drive 203. The ex- 

15 ternal disk drive 202 is operable to receive, read and 
write to one or more external data storage devices, such 
as a floppy disk, tape, or compact disk, while the hard 
disk drive 203 is operable to provide fast access data 
storage and retrieval functions, in a known manner. 

20 In addition, the computing system 200 preferably in- 
cludes one or more data communication ports for serial 
or parallel data communication with remote devices. For 
example, the processing unit 206 may be further con- 
nected to a network interface 209, such as an ATM host 

25 adapter card commercially available from Fore Sys- 
tems, Inc. of Pittsburgh, Pennsylvania. 

FIG. 2B illustrates a schematic block diagram of a 
microprocessing system, which may be utilized in con- 
junction with the general purpose computing system 

30 200 in FIG. 2 A. The microprocessing system includes a 
processing unit 206 ; which maybe embodied as a single 
processor or a number of processors operating in par- 
allel, coupled via data bus 270 with the memory storage 
device, such as the RAM 207, and the network interface 

35 209. The memory storage device 207 is operable to 
store one or more instructions which the processing unit 
206 is operable to retrieve, interpret and execute. In ad- 
dition, the memory storage device 207 stores the pro- 
gram code associated with the operating system 275, 

40 discussed further below in conjunction with FIGS. 4A 
through 4C. 

The processing unit 206 includes a control unit 250, 
an arithmetic logic unit (ALU) 255, and a local memory 
storage device 260, such as, for example, a cache or a 

45 plurality of registers. The control unit 250 is operable to 
retrieve instructions from the memory storage device 
207. The ALU 255 is operable to perform a plurality of 
operations needed to carry out instructions. The local 
memory storage device 260 is operable to provide high 

50 speed storage used for storing temporary results and 
control information. 

CONCEPTUAL REPRESENTATION OF RESOURCES 
IN A NAME SPACE 

55 

As previously indicated, the distributed computing 
environment 100 allows a user to access a plurality of 
local and remote resources. Preferably, every resource 
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in the system is implemented as a hierarchical "file" sys- 
tem, comprised of a tree of the file-like objects that are 
provided by the resource. In this manner, a user may 
access each resource in a uniform, file-oriented manner, 
even if the resource being accessed is not a file in the 
traditional sense. 

In the discussion which follows, the term "file" in- 
cludes traditional files, as well as other file-like objects. 
It is noted that each file in the name space of a user or 
a process is represented as a channel data structure, 
discussed below in conjunction with FIGS. 5 and 6. 

Thus, hierarchical file systems are utilized to repre- 
sent traditional file systems, such as those provided by 
the file servers 1 30-131 , as well as other non-traditional 
resources, such as physical devices and processes. For 
example, an RS232 line may be represented as a hier- 
archical file system comprised of a directory containing 
a datalWe and a control file. When data is written to the 
data file, the data is transmitted on the associated 
RS232 line. Similarly, data received on the associated 
RS232 line is obtained by reading the dataf\\e. The con- 
trol file contains a listing of control parameters associ- 
ated with the RS232 line, which may be modified to 
change parameters, such as the bit rate, of the physical 
device. 

The operating system 275 allows each file in the file 
system to have an alphanumeric name or label associ- 
ated with it, which can later be utilized by a user to locate 
the file in the name space In addition, the user can spec- 
ify the relationship between files, thereby allowing files 
to be organized into a hierarchical tree of directories and 
files. It is noted that directories are actually files contain- 
ing information on the location of other files. 

Conceptually, the hierarchical tree of directories 
and files provides a mechanism for maintaining the re- 
lationship between names and entities, and permits a 
user to locate the object by means of a pathname. A 
pathname of a file is defined to be an alphanumeric 
string which identifies a file by specifying a path through 
the hierarchical structure to the file. In one embodiment, 
a pathname consists of the 7" character, representing 
the root directory, together with the names of all of the 
directories between the root directory and the desired 
file, each separated by the slash character. 

A user or a process will assemble a private view of 
the set of resources available in the distributed comput- 
ing environment 100 by selecting one or more desired 
resources to form a customized name space for the as- 
sociated user or process. For example, as shown in FIG. 
3A, a user operating on a terminal 305 may wish to be 
connected to one file server 310, for example, where 
personal files reside, as well as to a second file server 
315, such as a departmental file server where the soft- 
ware for a particular group project is being written. 

The operating system 275 will typically provide a 
terminal, such as the terminal 305, with a minimum de- 
fault name space 320 each time the terminal is booted 
up. The default name space 320 may include, for exam- 



ple, input and output services, the binary code for exe- 
cuting the processor on the terminal 305 and a process 
service. For a more detailed discussion of the default or 
"stub" name space in the illustrative Plan 9 distributed 
s processing system, see, for example, U.S. Patent Ap- 
plication Serial No. 08/237,967, filed May 3, 1994, in- 
corporated above. 

For illustrative purposes, however, the default name 
space 320 of the terminal 305 shown in FIG. 3A includes 
just a root directory, /, containing two files, Xand Y. The 
files X and Y will serve as mount points, discussed fur- 
ther below in conjunction with FIGS. 4C and 7, where 
the file systems provided by other resources may be 
mounted upon. As shown in FIG. 3A, the file server 310 
provides a name space 325 and the file server 315 pro- 
vides a name space 330. The user terminal 305 can 
modify the default name space 320 to form a modified 
name space 320', shown in FIG. 3B, by making the file 
X in the name space 320 equivalent to the root, /, of the 
name space 325 provided by the server 310, and mak- 
ing the file Y in the name space 320 equivalent to the 
root, /, of the name space 330 provided by the server 
315. 

In order to join the name spaces 325 and 330 of 
each connected service 310 and 315, respectively, to 
the user's local name space 320', the appropriate con- 
nections through the network 340 must be established. 
The mechanisms for establishing the network connec- 
tions and for joining the name space of a particular re- 
mote service to the desired location of the name space 
320 associated with the terminal 305 are described be- 
low in conjunction with FIG. 7. 

It is noted that in addition to the default name space 
provided by the operating system 275 to each user, a 
particular user can typically customize their name space 
by writing a name space profile. The user-customized 
profile is a file typically stored in the user's personal di- 
rectory in the default name space and contains a list of 
resources or services to which the user should automat- 
ically be attached, in addition to the default resources, 
and indicates where in the user's name space they 
should be attached. For example, a user's profile may 
indicate the home file server that will be utilized by the 
user and indicate that the root of the home file server 
should be attached to the root of the user's local name 
space, /. In addition, the user's profile may indicate that 
the process file system should be attached to a directo- 
ry, /proc, found in the default name space. 

Thus, upon logging in to the distributed computing 
environment 100, a particular user will be automatically 
provided with the default name space, as modified by 
the user's customized profile, hereinafter collectively re- 
ferred to as the user's predefined name space. The us- 
er's predefined name space is formed by executing the 
series of predefined name space modification com- 
mands associated with the default name space and the 
user's customized name space. 

In addition, during operation, the user may execute 
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dynamic name space modification commands, which 
serve to further modify the user's predefined name 
space. It is noted that a dynamic name space modifica- 
tion command is defined herein to include any name 
space modification command executed by a user or 
process that is not included in the list of predefined name 
space modification commands associated with the us- 
er's predefined name space. Thus, dynamic name 
space commands would typically include any name 
space modification command executed by a user or 
process after logging in to the distributed computing en- 
vironment 100. 

For example, the illustrative Plan 9 distributed 
processing system provides a pair of name space mod- 
ification commands, namely, bind and mount. The bind 
command makes a file or directory in the current local 
name space, represented as a channel data structure, 
referred to herein as a "from" file, equivalent to another 
portion of the current name space, represented as an- 
other channel and referred to as the "to" file. In other 
words, the "to" channel is bound to the "from" channel. 
Thus, following execution of a bind command, referenc- 
es to the file specified by the "from" pathname will be 
interpreted as references to the file specified by the "to" 
pathname 

The mount command makes a name already in the 
current local name space, represented as a channel, re- 
ferred to herein as the "from" file, equivalent to the root 
of a non-kemel file system, such as a remote file server, 
referred to herein as the "to" file, represented as another 
channel In other words, the mount command mounts 
the channel representing the root directory of a non-ker- 
nel file system upon a channel representing an indicated 
portion of the current name space. It is noted that the 
root directory provides access to the entire hierarchical 
file tree provided by the non-kernel file system. Thus, 
following execution of a mount command, references to 
the file specified by the "from" pathname, which has 
been mounted upon, and any files below it in the hier- 
archy, will be interpreted as references to the files in the 
file tree of the non-kernel file system and thus become 
request messages written to the communication stream. 
In the example of FIG. 3A, the root directory, A of the 
remote tile server 310, has been mounted upon the file 
X in the default name space 320 of the terminal 305. 

In addition, the bind and mount commands prefer- 
ably allow different kinds of relationships to be specified 
among the "from" and "to" files. First, the user or process 
can preferably specify that whatever is referred to by the 
"to" file completely replaces whatever is referred to by 
the "from" pathname. In addition, the user or process 
can specify that the "from" and "to" pathnames form a 
union directory comprised of the files in both the "from" 
and "to" directory files. Essentially, the union directory 
is a directory with several mounted services. Preferably, 
the user or process can specify whether the "from" di- 
rectory is searched before or after the "to" directory in 
the resulting union directory 



Thus, the current state of the name space associ- 
ated with a user or process is determined by the list of 
predefined name space modification commands asso- 
ciated with the default name space 320, as modified by 
s the user-customized profile, as well as by the dynamic 
name space modification commands that were execut- 
ed by the user or process. It is noted that the default 
name space and user-customized profile, which form 
the user's predefined name space, are typically stored 
as files in the name space of the user or process. Ac- 
cording to a feature of the present invention, the list of 
dynamic name space modification commands, such as 
the subsequently executed mounts and binds, are 
stored in a mount table 800, discussed below in con- 
junction with FIGS. 8Aand 8B, which contains an entry 
for each mount and bind. The mount table 800 prefera- 
bly allows the list of mounts and binds to be retrieved 
from the table 800 in the order in which they were exe- 
cuted. It is noted, however, that the list of dynamic name 
space modification commands retrieved from the mount 
table 800 is in terms of the particular channel data struc- 
tures that were bound or mounted, and is not in terms 
of more useful file pathnames. 

Thus, according to further features of the invention, 
discussed below, additional data structures, discussed 
in conjunction with FIGS. 11 A through 11C, are provided 
that store path information which allows the pathname 
corresponding to each channel to be determined. In ad- 
dition, as discussed below, the stored path information 
allows the name space of the accessed files in the tree 
of each connected non-kernel file system to be recreat- 
ed. 

OPERATING SYSTEM KERNEL 

In many distributed processing systems, such as 
the preferred Plan 9 distributed processing system, the 
operating system 275 is structured as a kernel 400, il- 
lustrated in FIG. 4A. A kernel 400 typically provides an 
interface to every resource in the distributed computing 
environment 100. Conceptually, a kernel 400 can be 
viewed as having a process manager 410, as well as a 
name space manager 420. The process manager 410 
typically includes program code for controlling memory 
management, process scheduling, and control of the 
fork system call. Since process managers 410 are well 
known and have been discussed in detail elsewhere, the 
process manager 410 will be discussed herein only to 
the extent necessary to provide a clear understanding 
of the present invention. 

As previously indicated, the kernel 400 provides an 
interface to every resource in the distributed computing 
environment 1 00, whether or not the resource is actually 
implemented by the kernel 400. In the Plan 9 distributed 
processing system, for example, the name space man- 
ager 420 includes a device table 450, devtab, discussed 
below in conjunction with FIG. 4B, which serves as the 
interface to every device in the distributed computing 
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environment 100. 

In order to resolve names in the name space of a 
user or a process, the name space manager 420 in- 
cludes a pathname-to-channel convertor 1200, dis- 
cussed below in conjunction with FIG. 12. As indicated s 
above, a user can specify a particular file to be operated 
on in terms of a pathname in the user's name space. 
The pathname-to-channel convertor 1200 will translate 
the pathname into the particular channel .data structure 
representing the file to be operated on. 

In addition, the kernel 400 preferably implements a 
walkt unction 1300, discussed below in conjunction with 
FIG. 1 3, to move from one level of the file tree to another. 
A domounHunction 1500, discussed below relative to 
FIG. 1 5, is preferably provided by the kernel 400 to take 
a channel, determine if its meaning has been altered by 
being bound or mounted upon, and if so, perform the 
necessary channel substitutbn. A read name space 
subroutine 1700, shown in FIG. 17, during the exporta- 
tion of a process to a remote processor, will preferably 
access the mount table 800 to generate a list comprised 
of the "from" and "to* files associated with each bindand 
mount command that form the current state of the local 
name space. Finally, the kernel 400 preferably provides 
a channel-to-pathname convertor 2000, discussed be- 
low in conjunction with FIG. 20, which translates a given 
channel into its corresponding pathname, in the name 
space of the server that provides the file. 

As shown in FIG 4B, the device table 450 is pref- 
erably implemented as an array of device-specific pro- 
cedure calls that are utilized to perform a desired file 
operation on a file provided by a particular device. The 
device table 450 includes a pointer to a procedure call 
for every operation, such as open, read and write, that 
can be performed on a file provided by a particular de- 
vice. Thus, each kernel resident device is implemented 
by a device driver containing a procedure for each prim- 
itive operation. 

As shown in FIG. 4B, the device table 450 includes 
a plurality of rows, such as the rows 461-464, each as- 
sociated with a particular kernel-implemented device, 
such as a disk device or a teletype (tty) device. In addi- 
tion, the device table 450 includes a plurality of columns, 
such as the columns 452-457. The entries in column 452 
of the device table 450 indicate the particular device as- 
sociated with a given row in the table 450. The remaining 
columns, such as the columns 453-457, are each asso- 
ciated with a particular procedure call. For example, in 
order to open a file provided by the disk device associ- 
ated with row 461 , the kernel 400 should execute the 
procedure call diskopen, indicated in cell 468 of the de- 
vice table 450 

It is noted that the entries in row 464 of the device 
table 450 are associated with a special kernel device, 
referred to as the mount device 470, or mount driver, 
shown in FIG. 4C. The mount device 470 is a portion of 
the kernel 400 which provides an interface to all of the 
devices, such as the file systems 480-482, in the distrib- 



uted computing environment 100 that are not imple- 
mented by the kernel 400. It is noted that a non-kernel 
file system 480-482 may reside on the same node in the 
distributed computing environment 100 as the kernel 
400, or on a remote node. 

When the non-kernel file system 480-482 is resi- 
dent on the same node as the kernel 400, interprocess 
comm unication is preferably by means of a conventional 
pipe. In addition, when the non-kernel file system is lo- 
cated on a remote node, interprocess communication is 
by means of one or more network connections. As dis- 
cussed further below in conjunction with FIG. 7, the 
mount device represents the communication link 
476-478, which may be a pipe or a network connection, 
to the non-kernel file system 480-482 as a mount point, 
such as the mount points 472-474, consisting of a plu- 
rality of related data structures. 

It is noted that the mount device 470 will preferably 
provide a single mount point 472-474 for each connect- 
ed non-kernel file system, such as the file systems 
480-482. Thus, any process wishing to access a given 
remote file system will utilize the same mount point 
472-474. Accordingly, the mount device 470 must be 
able to demultiplex transmissions received for the one 
or more processes which may be communicating with 
the associated remote service. 

In a distributed computing environment 100, file op- 
erations are frequently performed on remote files. Gen- 
erally, a first process, desiring to perform an operation 
on a remote file, will send a message to a second proc- 
ess that provides the file. The transmitted message re- 
quests the second process to perform a particular task 
on the indicated file. Once the second process has per- 
formed the requested task, the second process will re- 
turn a reply to the first process with the result, which may 
be just an acknowledgement 

The mount device 470 preferably acts as an inter- 
mediary between the first and second processes to 
translate the procedure call executed by the first proc- 
ess into file operation messages that may be transmitted 
to the second process over an established communica- 
tion link, such as the links 476-478. The file operation 
messages transmitted across the communication link 
are referred to as remote procedure calls (RPCs), dis- 
cussed below in conjunction with FIG. 7. 

Thus, if a process wishes to perform a particular op- 
eration on a file provided by a non-kernel file system, 
such as the file systems 480-482, the process will exe- 
cute the procedure call corresponding to the desired op- 
eration. The kernel will recognize that the file is provided 
by a non-kernel file system and thereafter utilize the 
mount device 470 to translate the procedure call into the 
appropriate remote procedure calls. The remote proce- 
dure call message will request the remote file system to 
perform the desired task. Thereafter, the remote file sys- 
tem will send a reply to the mount device 470. The mount 
device 470 will, in turn, forward the results of the file op- 
eration to the requesting process. Thus, the mount de- 
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vice 470 hides the details of sending and receiving the 
request and reply messages behind the procedural in- 
terface. 

ACCESSING RESOURCES IN THE DISTRIBUTED 
SYSTEM 

When a particular file is opened by a process, the 
kernel 400 typically assigns a file descriptor, fd, or a nu- 
meric label, to the file. In addition, the kernel 400 utilizes 
a kernel data structure, hereinafter referred to as a chan- 
nel, discussed below in conjunction with FIG. 6, to rep- 
resent each file that a process may access in the name 
space. The kernel 400 maps the file descriptor, fd, to an 
assigned file, by using a file descriptor array 500, shown 
in FIG. 5. Each entry in the file descriptor array 500 is 
indexed by a file descriptor, fd, and contains a pointer 
in column 504 to the particular channel, such as the 
channels 520-521 , associated with the file descriptor in- 
dicated in column 502. 

In a preferred embodiment, the kernel 400 main- 
tains a file descriptor array 500 for each active process. 
Thus, the set of channels 520-522 pointed to by the file 
descriptor array 500 represents the collection of files to 
which the particular process is connected, in other 
words, the set of files in the name space of the associ- 
ated process. 

In addition, the kernel 400 preferably also maintains 
a process data structure 550, shown in FIG 5, for each 
active process. The process data structure 550 stores 
information necessary to manage the execution of the 
process, in a known manner. The process data structure 
550 includes, among other things, an entry 555 for stor- 
ing a pointer to the file descriptor array 500 associated 
with the process. In addition, the process data structure 
550 includes an entry 560 for storing a pointer to the 
channel 520 corresponding to the root directory, /, in the 
name space of the process, and an entry 565 for storing 
a pointer to the channel, such as the channel 521 , cor- 
responding to the current working directory in the name 
space of the process. 

As previously indicated, the kernel 400 utilizes a 
kernel data structure, referred to as a channel, to repre- 
sent each file that a given process may access in the 
name space. One suitable implementation of a channel 
data structure 600 is illustrated in FIG. 6. The channel 
600 preferably includes an element 605 for recording 
the typeoi kernel service device which provides the cor- 
responding file, such as the disk device or the tty device. 
The kernel service device type is utilized as an index 
into the device table 450, and thereby allows the proce- 
dure call corresponding to the appropriate device to be 
performed on the file. It is noted that for a non-kernel 
implemented file, the kernel service device type will in- 
dicate the mount device 470. 

For example, if a particular process desires to read 
a file, the process will execute a read command with the 
appropriate arguments, including the file descriptor, fd, 



indicating the channel associated with the file to be read. 
The kernel 400 will utilize the file descriptor, fd, to access 
the appropriate channel 600, by means of the file de- 
scriptor array 500, and thereafter identify the kernel 
s service device type providing the file, indicated in data 
structure element 605. Thereafter, the device type is 
used an index into the device table 450 to implement 
the procedure call corresponding to the particular de- 
vice 

10 in addition, the channel 600 preferably includes an 
element 610 for storing a file identifier, fid, assigned by 
the local kernel 400 to identify the file associated with 
the channel 600 and an element 615 for storing a qid, 
which is a unique number assigned by the server which 

is provides the file to each file in the server's file tree. It is 
noted that although a given process may have more 
than one channel 600 pointing to the same file, each 
having a different file identifier, fid, each channel point- 
ing to the same file will have the same unique qid. Since 

20 the type field identifies the resource that provides the 
file, the qid and type values may be utilized to uniquely 
identify any file and thus, to determine whether two dif- 
ferent channels or file identifiers, fids, point to the same 
file. 

25 The channel 600 preferably also includes a pair of 
elements for storing informatbn utilized when executing 
a read or write command on the associated file. An el- 
ement 620 preferably stores the current offset into the 
file associated with the channel, which indicates the po- 

30 sition of the associated file at which the next readox write 
command will begin. In addition, an element 625 pref- 
erably indicates the mode with which the file may be ac- 
cessed, in other words, whether the file may only be 
read, written or both. 

35 As previously indicated, if a file is provided by a non- 
kernel file system, the respective file is accessed indi- 
rectly through a mount point, discussed below in con- 
junction with FIG. 7, provided by the mount service 470. 
The mount point consists of a plurality of data structures 

40 representing the communication link to the non-kernel 
file system. Thus, if a channel 600 represents a file pro- 
vided by a non-kernel file system, an element 630 in the 
channel 600 is preferably populated with a pointer to the 
appropriate mount point structure, shown in FIG. 7, rep- 

45 resenting the communication link to the desired non-ker- 
nel file system, such as a remote file server. 

In addition, as discussed above, a user can utilize 
name space modification commands to create a union 
directory in the name space, consisting of at least two 

50 directories. Thus, a channel in the name space is made 
equivalent to the union directory, and is then said to rep- 
resent the union directory. When a channel 600 repre- 
sents a union directory, an element 635 in the channel 
600 is preferably populated with a pointer to the current 

55 directory in the union directory. As discussed below in 
conjunction with FIG. 13, a walk function 1300 can be 
utilized to step through each element of the union direc- 
tory. Preferably, the pointer 635 is appropriately updated 
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as the channel 600 points at different elements of the 
union directory 

As indicated above, the present invention provides 
data structures for storing name space or path informa- 
tion that allows the file pathname corresponding to a giv- 
en channel to be accurately reproduced. According to 
one feature of the present invention, discussed below 
in conjunction with FIG. 11 C, a path data structure 1 1 40, 
associated with each file, stores the name of the file, 
and additional information that allows the path through 
the name space to the particular file to be determined. 
Thus, each channel 600 preferably contains an element 
640 for storing a pointer to the path structure 1140 as- 
sociated with the given file represented by the channel. 
Finally, each channel 600 preferably includes a refer- 
ence counter 645 which monitors the number of pointers 
currently pointing to the particular channel. Thus, when 
the reference counter is zero, indicating that there are 
no pointers currently pointing to the channel, the data 
structure may be freed, in a known manner. 

COMMUNICATING WITH NON-KERNEL FILE 
SYSTEMS 

As previously indicated, each file in the name space 
of a particular user or process is represented by a chan- 
nel data structure, such as the channel 600, whether or 
not the file is maintained by the local kernel 400 or by a 
non-kernel file system When a particular channel 600 
represents a non-kernel implemented file, however, the 
respective file is accessed indirectly through a mount 
point, such as the mount points 472-474 shown in FIG. 
4C, provided by the kernel mount service 470. It is again 
noted that the mount service 470 will preferably create 
a single mount point, such as the mount point 472, for 
each connected non-kernel file system, such as the de- 
vice 480. Thus, the created mount point 472-474 may 
be utilized by a plurality of processes wishing to access 
files provided by the associated non-kernel file system. 

a. Creation of the Communication Link 

When a process initially attaches to a non-kernel 
file system 750, shown in FIG. 7, such as a remote file 
server, a communication link 740 must be established 
to the device 750. As previously indicated, if the non- 
kernel file system 750 is resident on the same node in 
the distributed computing environment 1 00, the commu- 
nication link 740 is preferably embodied as a conven- 
tional pipe. If, however, the non-kernel file system 750 
is resident on a remote node in the distributed comput- 
ing environment 100, then the communication link 740 
is a network connection. 

Typically, an operating system will provide a pipe 
system call which, when executed, will create a conven- 
tional interprocess communication pipe and return two 
file descriptors, fd 1 and fd 2 , identifying channels repre- 
senting each side of the pipe The pipe is accessed by 



the appropriate file decsriptor, fd 1 or fd 2 , like an ordinary 
file. Thus, the non-kernel file system 750 will read and 
write remote procedure calls from one side of the creat- 
ed pipe, using the first file descriptor, fd 1} while the one 
s or more processes communicating with the non-kernel 
file system 750 can utilize the second file descriptor, fd 2 , 
to read and write from the other side of the pipe. 

If, however, the non-kernel file system 750 is resi- 
dent on a remote node in the distributed computing en- 
vironment 1 00, then the communication link 740 is a net- 
work connection. Typically, the operating system asso- 
ciated with a distributed processing system will provide 
a command for creating a network connection to a re- 
mote file server. In the preferred Plan 9 distributed 
processing system, for example, a network connection 
is created by executing a dial command, with the appro- 
priate arguments, such as the symbolic name or net- 
work address of the desired destination. 

As discussed below in conjunction with FIG. 9A, the 
dial command uses a network data base 900, if neces- 
sary, to translate the symbolic name to a network desti- 
nation address. Thereafter, the dial command attempts 
to create a network connection to the indicated network 
address in the distributed computing environment 100. 
Once the desired network connection has been estab- 
lished, the dial command will return a file descriptor, fd, 
identifying a channel 730 that represents the created 
network connection. The manner in which a channel, 
such as the channel 730, can be utilized to transmit and 
receive messages on the network connection is dis- 
cussed below in conjunction with FIG. 9B. 

Thus, the channel 730, shown in FIG. 7, is identified 
by the file descriptor, fd, that is returned from the pipe 
or c//a7 command. The channel 730 represents the com- 
munication link 740, which may be a pipe or a network 
connection communicating with the non-kernel file sys- 
tem 750. 

In a preferred embodiment, when an application 
program creates a pipe or a network connection, in the 
manner just described, to communicate with a particular 
non-kernel file system, the returned file descriptor, fd, 
identifying the channel 730, which represents the creat- 
ed communication link 740, is posted in a file in a pre- 
defined place in the local name space. In one embodi- 
ment, discussed below in conjunction with FIG. 1 0, a file 
is created in a special kernel device, /srv, for each mount 
point 71 0, to store the file descriptor, fd, or pointer which 
identifies the channel 730. 

In this manner, before creating a new connection to 
a non-kernel file system, such as the device 750, the 
files in the /srv directory can be searched to determine 
if a connection to the particular non -kernel file system 
has already been established. If a previously estab- 
lished connection to the desired non-kernel file system 
is found, the file descriptor, fd, representing the commu- 
nication link can be retrieved from the file in the /srv di- 
rectory and mounted in the desired place in the name 
space. 
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b. Creation of the Mount Point 

In addition tothe channel 730, which represents the 
communication link 740 to the non-kernel file system 
750, the mount device 470 preferably allocates a mount s 
point data structure 710 for storing access and path in- 
formation regarding the non-kernel file system 750. The 
mount point data structure 710 preferably includes a 
pointer 712 to the channel data structure 730 that rep- 
resents the communication link 740 to the non-kernel 10 
file system 750. In addition, the mount point data struc- 
ture 710 preferably includes a queue 714, which con- 
tains a list of tags, each associated with an outstanding 
remote procedure call message, which will allow the 
mount point 710 to direct a reply received on the com- is 
munication link 740 to the appropriate requesting proc- 
ess. 

According to a feature of the present invention, the 
mount point data structure 710 also preferably includes 
a pointer 71 6 to a server tree path table 1100, discussed 20 
below in conjunction with FIG. 11 A, which stores point- 
ers to data structures containing name space informa- 
tion for each of the accessed files in the tree of the non- 
kernel file system 750. As discussed below, the stored 
name space information allows the file tree of the non- 2s 
kernel file system to be generated. 

In a preferred implementation, one channel, such 
as the channel 705, is automatically allocated upon cre- 
ation of the mount point 710 to represent the root direc- 
tory, /, of the file tree provided by the non -kern el file sys- 30 
tern 750. As indicated above, when a channel, such as 
the channel 705, represents a remote file, the element 
630 in the channel data structure is preferably populated 
with a pointer to the appropriate mount point structure 
710, which provides access to the communication link 35 
7 AO to the desired remote file server 750. 

As previously indicated, every channel, such as the 
allocated channel 705, will include a file identifier, fid, 
indicated in element 610 of the channel structure. The 
mount device 470 will preferably transmit an attach re- 40 
mote procedure call, including the file identifier, fid, in- 
dicated in element 61 0 of channel 705, to the non-kernel 
file system 750 across the communication link 740. The 
attach remote procedure call instructs the non-kernel file 
system 750 to point the indicated file identifier, fid, at the 45 
root of the file tree provided by the non-kernel file system 
750. 

In a preferred embodiment, the channel 705 will 
point at the root directory of the file tree of the non-kernel 
file system 750, for as long as the communication link so 
740 to the device 750 is maintained. Thus, if a user or 
process wishes to access other files in the file tree of 
the non-kernel file system 750, the channel 705 should 
be copied using a clone command, in a known manner. 
Thus, the mount table 800 will not be modified each time ss 
a file provided by the non-kernel file system 750 is ac- 
cessed. The copy of channel 705 will initially point at the 
root directory, /, of the non -kernel file system 750 The 



copy of channel 705 can then be manipulated to point 
at other files in the file tree of the non-kernel file system 
750, by executing a walk command 1 300 to move from 
one level of the file tree to another, as discussed below 
in conjunction with FIG. 1 3. These commands are typi- 
cally transmitted to the non-kernel file system 750 by 
means of remote procedure calls. 

c. Mounting the Root Directory of a Non-Kernel Fife 
System 

As indicated above in conjunction with FIG. 3A, the 
file tree of the non-kernel file system 750 can be posi- 
tioned in the local name space by making the channel 
705, which represents the root directory of the non-ker- 
nel file system 750, equivalent to a file already in the 
local name space. In other words, a mount command 
can be executed to mount the channel 705 upon a file, 
represented by a channel, in the name space. For ex- 
ample, if the communication link 740, shown in FIG. 7, 
represents the connection from the terminal 305 to the 
remote file server 310, shown in FIG. 3A, then the chan- 
nel 705 represents the root, /, of the name space 325 of 
the server 31 0. Thus, to positbn the file tree of the server 
310 in the name space 320 associated with the terminal 
305, the channel 705 should be mounted upon the file, 
X, in the terminal's name space 320. 

As previously indicated, the kernel 400 utilizes a 
mount table 800 and related data structures, shown in 
FIGS. 8Aand8B, to store the series of binds and mounts 
executed by a user or process to form the local name 
space. Thus, continuing the example of FIGS. 3A and 
3B, if a user operating on the name space 320', associ- 
ated with the terminal 305, attempts to open a file, IYJ 
D, the kernel will utilize the mount table 800 to interpret 
the request to access file X, and any files below file X in 
the hierarchy, as references to a file, such as the file D, 
in the file tree of the file server 310. In a preferred em- 
bodiment, the kernel 400 will execute a pathname-to- 
channel convertor 1200, discussed below in conjunction 
with FIG. 12, each time a file is accessed using a 
pathname, which will, among other things, determine if 
a channel substitution is necessary due to a bind or a 
mount command. 

It is noted that the arguments of a bind or mount 
command are a "from" channel and a "to" channel. Thus, 
each entry in the mount table 800 will be comprised of 
pairs of "from" and "to" entries. If a channel appears in 
the mount table 800 as a "from" channel, then another 
channel has been mounted upon this channel, and a 
channel substitution must be performed. 

Accordingly, each time a file is accessed using a 
pathname, the kernel 400 will convert the pathname to 
the corresponding channel and then search the mount 
table 800 to determine if the particular channel has been 
mounted upon, in other words, if the channel appears 
in the list of mount "from" channels. If the channel is 
found in the list of mount "from" channels, the corre- 
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spending mount "to" entry in the mount table 800 will be 
retrieved to perform the necessary channel substitution 

As indicated above, the qid and type values stored 
in elements 615 and 605, respectively, of each channel, 
such as the channel 600, uniquely identify the file cor- s 
responding to the channel. Thus, channels are prefera- 
bly identified in the mount table by their qid and type 
values. In a preferred embodiment, entries in the mount 
table 800 are indexed by a hash value based on the qid 
value of the channel which has been mounted upon. 
Thus, to determine if a particular channel has been 
mounted upon, the mount table 800 is entered with the 
corresponding qid value. Thereafter, the list of mount 
"from" channels are searched for channels having the 
same qid and type values. If a match is found, the kernel 
will perform the channel substitution indicated by the 
corresponding mount "to" channel entry. 

Conceptually, the mount table 800 can be viewed 
as a top-level data structure, comprised of a pair of col- 
umns 805 and 810. Each entry in the hash address col- 
umn 805 is populated with a unique hash value, which 
serves as an index or address for each row of the mount 
table 800, such as the rows 815, 820 and 825. 

It is noted that a number of different qid values may 
hash to the same hash value. Accordingly, each row of 
the mount table 800, such as the row 820, may be as- 
sociated with a plurality of channels which have been 
mounted upon, each uniquely identified by the qid and 
type values. Thus, the corresponding entry in the "point- 
er to linked list 1 * column 81 0, if populated, will preferably 
contain a pointer 828 to a linked list of data structures 
826, comprised of structures 830, 832 and 837, associ- 
ated with the hash value. 

The presently preferred embodiments of the mount 
"from" and mount "to" data structures are shown in FIG. 
8B. Generally, as shown in FIG. 8A, each data structure 
in the linked list of mount "from" data structures 826, 
such as the structures 830, 832 and 837, will have a 
pointer, such as the pointer 829, to the next data struc- 
ture in the linked list. The final data structure 837 in the 
linked list will preferably have a null pointer, as shown 
in FIG. 8A. 

As previously indicated, each entry in the mount ta- 
ble 800 will be comprised of a "from" data structure, rep- 
resenting the channel mounted upon, and at least one 
"to" data structure, representing the one or more mount- 
ed channels. As shown in FIG. 8B, the linked list pointer 
828 from the top-level mount table 800 will point to a 
mount "from" data structure 830 in the linked list 826. 

A mount "from" data structure, such as the structure 
830, preferably contains an entry 840 for storing a point- 
er to the channel which has been mounted upon, as well 
as an entry 845 for storing a pointer to an associated 
mount "to" data structure 850. It is noted that if the 
mounted channel is part of a union directory, the mount 
"to" data structures will be a linked list of structures, such 
as the linked list 880. In addition, each mount "from" data 
structure, such as the structure 830, will preferably con- 



tain an entry 848 for storing a pointer 829 to the next 
element in the linked list 826. 

In a preferred embodiment, the kernel 400 includes 
a domounHunction 1500, illustrated in FIG. 15, which 
will take a channel, determine if its meaning has been 
altered by being mounted upon, and if so, perform the 
necessary channel substitution. As discussed below, 
the domount function 1500 will retrieve the qidUom the 
received channel, generate the hash value, and utilize 
the linked list pointer 828 from the appropriate entry in 
column 810 to access the appropriate linked list of 
mount "from" data structures, such as the linked list 826. 
Thereafter, the kernel 400 will successively follow the 
pointer to each mount "from" struct u re , such as the 
structure 830, in the linked list of data structures 826 to 
determine if a channel pointed to by a mount "from" 
structure in the linked list has the same qid and type 
values as the channel that was passed to the domount 
function 1500. 

If a channel is found having matching qid and type 
values, the pointer in entry 845 of the mount "from" 
structure 830 is followed to the first element of the as- 
sociated linked list 880 of mount "to" data structures, 
such as the data structure 850. Preferably, each mount 
"to" linked list data structure 850 contains an element 
855 for storing a pointer to the mounted channel. In ad- 
dition, the mount "to" linked list data structure 850 pref- 
erably includes an element 860 for storing a mountidval- 
ue which uniquely identifies the entry in the mount table 
800. In a preferred embodiment, the mountid value is 
incremented each time an entry is added, and thereby 
serves as a time stamp which allows the mount table 
entries to be retrieved from the mount table 800 in the 
order in which the corresponding bind and mount com- 
mands were executed. 

In addition, the mount "to" linked list data structure 
850 preferably contains an element 865 for storing a 
pointer back to the associated mount "from" linked list 
data structure 830. In addition, the mount "to" linked list 
data structure 850 contains an element 870 for storing 
the mount order flags that were specified in the bind ox 
mount command associated with the mount table entry. 
In other words, whether the associated bind or mount 
command indicated that the current directory in the un- 
ion directory should be before or after the other directo- 
ries in the union. Finally, the mount to" linked list data 
structure 850 preferably contains an entry 875 for stor- 
ing a pointer to the next element in the linked list 880 of 
mount "to" data structures. 

NETWORK REPRESENTATION 

As previously indicated, a network data base 900, 
shown in FIG. 9A, may be utilized to provide translations 
between symbolic machine names and network desti- 
nation addresses. When establishing a network connec- 
tion, for example, a user or process may request a con- 
nection to a desired remote machine, identified by a 
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symbolic machine name. Thus, during the connection 
phase, the network data base 900 is accessed to trans- 
late the indicated symbolic name to a corresponding 
network destination address. In addition, according to a 
feature of the invention discussed below, when recreat- 
ing the name space it is often necessary to translate a 
network destination address back into a symbolic ma- 
chine name. 

Thus, the network data base 900, shown in FIG. 9A, 
is preferably comprised ol a pair of columns 925 and 
930. Each row in the data base 900, such as the rows 
905, 910 and 915, is preferably associated with a par- 
ticular remote machine. Thus, each entry in column 925 
indicates the symbolic machine name associated with 
the particular machine. The associated entry in column 
930 preferably contains a list of the networks to which 
the particular machine is connected, together with the 
appropriate network destination address. Thus, the ma- 
chine helix, for example, has a destination address 
135.104.9.31 on the ip network. 

In this manner, if a user or process requests a net- 
work connection to a particular remote machine, such 
as the machine helix, the kernel 400 will access the ap- 
propriate entry in the network data base 900 and retrieve 
the corresponding network destination addresses of the 
machine. Preferably, a connection will be attempted to 
each retrieved destination address, in turn, until a suc- 
cessful connection is established. 

A network, like any other resource in the distributed 
computing environment 100, is preferably represented 
as a hierarchical file system. FIG. 9B illustrates a portion 
of the name space 950 related to networks. The name 
space 950 preferably contains a directory, /net, which 
contains a subdirectory for each network that may be 
accessed, such as the networks il and tcp. In addition, 
each network directory, such as the network directory / 
net/il, preferably contains a clone file and a set of num- 
bered directories, each corresponding to a network con- 
nection. Each numbered directory contains files to con- 
trol and communicate on the associated connection. 

As discussed below, a new network connection is 
allocated by opening the clone file in the network direc- 
tory of the desired network, such as the file /net/i l/clone, 
to reserve an unused connection. The file descriptor, fd, 
returned by the open command will identify a channel 
which points to the control file of the new connection. 
Thereafter, to establish the connection, an ASCII ad- 
dress string is written to the control file of the new con- 
nection, such as "connect 135. 104. 9.30! 17008" to con- 
nect to the bootes machine on the il network. 

Thereafter, reads and writes to the associated data 
file will allow data to be received and transmitted on the 
established connection, respectively. It is noted that the 
listen file is used to accept incoming calls from the net- 
work ; the local file typically contains addressing infor- 
mation, and the remote and status files provides infor- 
mation on the connection status For further details on 
the creation and utilization of network connections in a 



distributed computing environment 100, such as the 
Plan 9 distributed computing system, see David Presot- 
to & Philip Winterbottom, "The Organization of Networks 
in Plan 9", Proc. of the Winter 1993 USENIX Technical 
s Conference, San Diego, CA., pp. 43-50 (1993), incor- 
porated by reference herein. 

As discussed above in conjunction with FIG. 7, each 
time a communication link, such as a pipe or a network 
connection, is established to a non-kernel file system, 
10 the file descriptor, fd, which is returned by the pipe or 
dial command to identify the channel which represents 
the created communication link, is preferably posted in 
a file in a predefined place in the local name space. In 
one embodiment, illustrated in FIG. 10, a file is created 
15 in a directory, /srv, for each created mount point to store 
the file descriptor, fd, or pointer, which identifies the 
channel representing the communication link. 

In the illustrative implementation, files created in the 
/srv directory for storing a pointer to a channel corre- 
sponding to a pipe are named in accordance with the 
following convention: programname.username.procid. 
Thus, the file, &&.philw.35, stores a pointer to a channel 
associated with a pipe to the Plan 9 window system, 8 1 /£, 
for the user, philw. Similarly, files created in the /srv di- 
rectory for storing a pointer to a channel corresponding 
to a network connection are named in accordance with 
the following convention: network! machine name. Thus, 
the file, il! bootes, stores a pointer to a channel associ- 
ated with a network connection to the machine bootes 
across the ii network. 

In this manner, before creating a new connection to 
a non-kernel file system, such as the device 750, the 
files in the /srv directory can be searched to determine 
if a connection to the particular non-kernel file system 
has already been established. Thus, if a connection to 
a desired non-kernel file system has already been es- 
tablished, the channel indicated in the /srv directory can 
be mounted into the desired place in the name space. 

In addition, the information stored in the files in the 
/srv directory may be utilized to identify the pipes and 
network connections when packaging the name space 
for transmission tothecpu server, during the exportation 
of a processing task, as described below in conjunction 
with FIG. 16A. 

NAME SPACE INFORMATION DATA STRUCTURES 

As previously indicated, the list of mounts and binds 
executed by a user or process to form the name space 
can preferably be retrieved from the mount table 800 in 
the order in which they were executed. It is noted, how- 
ever, that the list of bind and mount commands retrieved 
from the mount table 800 is in terms of the particular 
channel data structures that were bound or mounted, 
and is not in terms of file pathnames. 

Thus, according to further features of the invention, 
path data structures, shown in FIGS. 11 A through 11C, 
store path information which allows the pathname cor- 
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responding to each channel to be determined. In addi- 
tion, as discussed below, the stored path information al- 
lows the name space of the accessed files in the tree of 
each connected non-kernel file system to be recreated. 

As previously indicated, the mount point data struc- 
ture 710, discussed above in conjunction with FIG. 7, 
which provides access to a remote server, includes a 
pointer 716 to a server tree path table 1100, shown in 
FIG. 11 A The server path tree table 1100 stores point- 
ers to data structures containing path information for 
each of the accessed files in the hierarchical file tree of 
the non-kernel file system 750 associated with the 
mount point 710. The stored path information allows the 
file tree of the non-kernel file system to be generated, 
in a manner described below. 

As shown in FIG. 11 A, the server tree path table 
1100 preferably consists of a pointer 1102 to the path 
data structure associated with the channel representing 
the root directory of the particular non -kernel file system, 
such as the channel 705 representing the root directory 
of the remote file system 750 As discussed below, the 
pointer 1102 to the path data structure of the root of the 
non -kernel file system can be utilized to identify when 
the pathname has been reconstructed from a given file 
in the hierarchy all of the way back up to the root direc- 
tory. 

In addition, the server tree path table 1100 prefera- 
bly includes a pointer 1 1 04 to a server tree path list 1110, 
shown in FIG 11B, which is preferably a list of pointers 
to the data structures containing path information for all 
of the accessed files in the file tree of the associated 
non-kernel file system In a preferred embodiment, the 
entries in the server tree path list 1110 are based upon 
pathname information for a given file. In other words, in 
a preferred embodiment, entries in the server tree path 
list 1110 are indexed by a hash value based on the 
pathname of a given file. In this manner, the appropriate 
path data structure, such as the data 5 structure 1140, 
associated with a given file can be easily identified for 
a file being accessed based upon a pathname, for ex- 
ample, during execution of the walk function 1300. It is 
noted that if path information is desired for a particular 
channel, the appropriate data structure can be directly 
accessed by retrieving the path structure pointer 640 
from the channel 600. 

Thus, to access the path information for a particular 
file, identified by its pathname, the server tree path list 
1110 is entered with a hash value based on the 
pathname of the given file. Conceptually, the server tree 
path list 1 1 1 0 can be viewed as a top-level data structure 
comprised of a pair of columns 1122 and 1124. Each 
entry in the hash address column 1 1 22 is populated with 
a unique hash value, which serves as an index or ad- 
dress for each row of the server tree path list 1110, such 
as the rows 1115, 1118 and 1120. 

It is noted that a number of different pathname val- 
ues may hash to the same hash value Accordingly, 
each row of the server tree path list 1110, such as the 



row 1118, may be associated with a plurality of path data 
structures. Thus, the corresponding entry in the "pointer 
to linked list - column 1124, if populated, will preferably 
contain a pointer 1128 to a linked list of data structures 

s 1126, comprised of structures 1130, 1132and 1137, as- 
sociated with the hash value. 

The presently preferred embodiment of a path data 
structure 1140 is shown in FIG. 11 C. Generally, as 
shown in FIG. 11 B, each data structure in the linked list 

10 of path data structures 1126, such as the structures 
1130, 1132 and 1137, will have a pointer, such as the 
pointer 1 1 29, to the next data structure in the linked list. 
The final data structure 1137 in the linked list will pref- 
erably have a null pointer, as shown in FIG. 11B. 

15 Each path data structure, such as the data structure 
1140, preferably contains an entry 1142 for storing the 
name of the associated file, an entry 1144 for storing a 
pointer to the path data structure of the parent to the 
current file, a reference counter 1146 and a linked list 

20 pointer 1148 to the next element in the linked list. As 
discussed below in conjunction with FIG. 20, the chan- 
nel-to-pathname convertor 2000 will utilize the path data 
structures, such as the data structure 1140, to construct 
the pathname for a given file, represented as a channel. 

25 Generally, given a channel, the channel-to-pathname 
convertor 2000 will access the path data structure 11 40 
for the indicated file to retrieve its file name from entry 
1 1 42, and then successively follow the series of pointers 
to the path data structure of the parent file, retrieved 

30 from entry 1144, up the file tree to construct the 
pathname until the root directory is reached. 

NAME SPACE PROCESSES 

35 As previously indicated, the kernel 400 provides a 
pathname-to-channel convertor 1200 for translating a 
given pathname in the name space of a user or process 
into the appropriate channel representing the indicated 
file. As indicated above, a user or process can perform 

40 a number of different file operations on a file, identified 
by a pathname in the name space of the user or process. 
Each of these file operations that receives a pathname 
argument to identify the file to be operated upon, will 
preferably call the pathname-to-channel convertor 1 200 

45 to translate the indicated pathname into the particular 
channel data structure, which represents the file, to be 
operated on. 

As discussed below, the pathname-to-channel con- 
vertor 1200 is comprised of three main portions. Parts I 

50 and II will identify the appropriate channel which repre- 
sents the directory containing the indicated file. It is not- 
ed that the different file operations that will call the 
pathname-to-channel convertor 1200 will be performing 
different tasks on the indicated file, identified by an ac- 

55 cess mode. 

For most file operations, such as open or create, it 
is desired to perform all channel substitutions indicated 
in the mount table BOO. When the file operation is set 
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working directory or a mount command, however, the 
file operation should be performed on a channel repre- 
senting the union directory itself, and not on a channel 
representing the first element in the union directory. In 
this manner, if a channel is inserted before the first ele- 5 
ment in the union by a subsequent bind or mount com- 
mand, the new first element will still be pointed to by the 
channel representing the union directory. Thus, a third 
portion 1245 of the pathname-to-channel convertor 
1 200 will evaluate the received access mode argument 10 
and, where appropriate, will not perform any channel 
substitutions indicated in the mount table 800 on the fi- 
nal pathname element. 

As shown in FIG. 12A, the pathname-to-channel 
convertor 1 200 is entered at step 1 204, with an indicated is 
pathname argument. During a first portion 1202 of the 
pathname-to-channel convertor 1200, corresponding to 
steps 1208 through 1224, the first element of the 
pathname is analyzed. It is noted that a pathname can 
typically start with one of three characters, each identi- 20 
tying a different origination point for the pathname. 
Thus, a test is performed during step 1208 to determine 
if the first character in the pathname argument is the 
slash character, indicating that the pathname has been 
specified relative to the root directory. If it is determined 2s 
during step 1 208 that the first character in the pathname 
argument does indicate the root directory, /, then the 
pointer to the channel representing the root directory is 
retrieved from element 560 of the process data structure 
550 (FIG. 5) and the corresponding channel is cloned, 30 
or copied, during step 1212. 

If, however, it is determined during step 1208 that 
the first character in the pathname argument does not 
indicate the root directory, /, then a test is performed dur- 
ing step 1216 to determine if the first character in the 3S 
pathname argument is the dot character, ., indicating 
that the pathname has been specified relative to the cur- 
rent working directory. If it is determined during step 
1216 that the first character in the pathname argument 
does indicate the working directory (.), then the pointer 40 
to the channel representing the working directory is re- 
trieved from element 565 of the process data structure 
550 (FIG. 5) and the corresponding channel is then 
cloned, or copied, during step 1220. 

If, however, it is determined during step 1216 that 45 
the first character in the pathname argument does not 
indicate the working directory (.), then the first character 
must be the hash character, #, indicating that the 
pathname has been specified relative to a kernel device. 
Thus, the kernel device identified by the second char- so 
acter of the pathname, such as #p, indicating the proc- 
ess device, is attached during step 1224. The file de- 
scriptor, fd, that is returned by the attach command, in 
a known manner, is assigned to the variable, channel. 

Following execution of the first portion 1 202 of the ss 
pathname-to-channel convertor 1200, the variable, 
channel, contains a channel representing the directory 
or file indicated by the first element of the pathname ar- 



gument. During a second portion 1 226 of the pathname- 
to-channel convertor 1 200, corresponding to steps 1 228 
through 1240, each successive element of the 
pathname argument is traversed until the final element 
of the pathname is reached. 

The next element of the pathname argument is re- 
trieved during step 1228. Thereafter, the walk function 
1300, discussed below in conjunction with FIG. 13, is 
executed during step 1 232, with the current value of the 
variable, channel, and the next element retrieved during 
the previous step. The result of the walk function 1300 
is assigned to the variable, channel Generally, the walk 
function 1 300 will search the directory represented by 
the current value of channel, for the file or directory in- 
dicated by the next element in the pathname. 

Following execution of the walkt unction during step 
1 232, a domountf unction 1 500, discussed below in con- 
junction with FIG. 15, is executed during step 1236. 
Generally, the domount function 1500 will access the 
mount table 800 to determine whether the channel rep- 
resented by the current value of the variable channel 
has been mounted upon. If the channel corresponding 
to the current value of the variable channel has been 
mounted upon, the value of the variable channel W\\\ be 
translated by the domount function 1500 to indicate the 
channel which has been mounted. 

Thereafter, a test is performed during step 1 240 to 
determine if there are additional elements in the 
pathname argument to be evaluated, other than the last 
element. If it is determined during step 1240 that there 
are additional elements in the pathname argument to be 
evaluated, then program control will return to step 1228 
to continue processing the remaining pathname ele- 
ments in the manner described above. 

If, however, it is determined during step 1240 that 
there are no additional elements in the pathname argu- 
ment to be evaluated, other than the last element, then 
program control will proceed to step 1250 (FIG. 12B). 
Following execution of the second portion 1226 of the 
pathname-to-channel convertor 1200, the variable, 
channel, is pointing to the next to last path element in 
the indicated pathname, in other words, the directory 
containing the file (or directory) identified by the 
pathname argument. 

As previously indicated, an argument received by 
the pathname-to-channel convertor 1200 identifies the 
access mode of the current file operation. As indicated 
above, the access mode will determine whether any 
channel substitutions indicated in the mount table 800 
should be performed on the last element of the 
pathname. The third portion 1245 of the pathname-to- 
channel convertor 1200, corresponding to steps 1250 
through 1290, evaluates the access mode argument 
and identifies the appropriate channel that represents 
the file. 

A test is performed during step 1250 to determine 
if the current access mode is access. If it is determined 
during step 1250 that the current access mode is ac- 



3 0738970A1J_> 



16 



31 



EP 0 738 970 A1 



32 



cess, then the walk function 1300, illustrated in FIG. 13, 
is executed during step 1254, with the current value of 
the variable, channel, and the last element of the 
pathname. The result of the walk function 1300 is as- 
signed to the variable, channel. The malfunction 1300 5 
will search the directory represented by the current val- 
ue of channel, for the file or directory indicated by the 
last element in the pathname. 

Following execution of the walk function during step 
1254, the domount function 1500, illustrated in FIG. 15, 10 
is executed during step 1258. The domount function 
1500 will access the mount table 800 to determine 
whether the channel represented by the current value 
of the variable channel has been mounted upon and if 
so, the value of the variable channel will be translated 1$ 
to indicate the channel which has been mounted. There- 
after program control will return to the calling file oper- 
ation during step 1 290 with the current value of the var- 
iable channel, which now represents the file to be op- 
erated upon. 20 

If, however, it is determined during step 1250 that 
the current access mode is not equal to access, then a 
test is performed during step 1262 to determine if the 
current access mode equals set working directory or 
mount. If it is determined during step 1262 that the cur- 26 
rent access mode is equal to set working directory or 
mount, then it is desired to have the channel represent 
the union directory itself, and not the first element in the 
union Thus, the walk function 1300, illustrated in FIG. 
1 3, is executed during step 1 264, with the current value 30 
of the variable, channel, and the last element of the 
pathname to search the directory represented by the 
current value of channel, for the file or directory indicat- 
ed by the last element in the pathname. The result of 
the walk function 1 300 is assigned to the variable, chan- 35 
nel. Thereafter, program control will return to the calling 
file operation during step 1290, without calling the do- 
mount function 1500, with the current value of the vari- 
able, channel. 

If, however, it is determined during step 1262 that 40 
the current access mode is not equal to set working di- 
rectory or mount, then a test is performed during step 
1268 to determine if the current access mode is equal 
to open or create. If it is determined during step 1268 
that the current access mode is equal to open or create, 45 
then the walk function 1300, illustrated in FIG. 13, is ex- 
ecuted during step 1272, with the current value of the 
variable, channel, and the last element of the pathname 
to search the directory represented by the current value 
of channel, for the file or directory indicated by the last so 
element \r\ the pathname. The result of the malfunction 
1 300 is assigned to the variable, channel. 

Following execution of the walki unction during step 
1272, the domounr function 1500, illustrated in FIG. 15, 
is executed during step 1276. The domount 1 unction 55 
1500 will access the mount table 800 to determine 
whether the channel represented by the current value 
of the variable channel has been mounted upon and if 



so, translate the value of the variable channelto indicate 
the channel which has been mounted 

It is noted that the task of opening a file requires 
certain permissions to be verified. Thus, during step 
1280, the manner in which the file may be accessed is 
evaluated. 

Thereafter, program control will return to the calling 
file operation during step 1290 with the current value of 
the variable, channel, which now represents the file to 
be operated upon. 

If, however, it is determined during step 1268 that 
the current access mode is not equal to open or create, 
then all of the valid access modes have been attempted 
and the current access mode must be an error. Thus, 
an error flag is preferably set during step 1284, before 
program control returns to the calling file operation. 

As previously indicated, the walk function 1300 
shown in FIG. 1 3, will receive a channel and a pathname 
element as arguments. As discussed below, the walk 
function 1300 will search the directory represented by 
the current value of channel, for the file or directory in- 
dicated by the pathname element. The walk function 
1300 will utilize a device walk subroutine 1400, shown 
in FIG. 14, to actually determine if the particular directory 
has the indicated file. In addition, since the received 
channel will point to a new file upon a successful walk, 
the device walk subroutine 1 400 will also update the ap- 
propriate path data structures 1140, if necessary. 

The walki unction 1 300 is preferably entered at step 
1305, as shown in FIG. 13. The arguments of the walk 
function 1 300 include a change/ representing a directory 
to be searched for a particular file, indicated by a given 
name element. 

The kernel service device type element 605 of the 
indicated channel, such as the channel 600, is evaluat- 
ed during step 1310 to identify the kernel device that 
provides the file. As previously indicated, the kernel 
service device type is utilized as an index into the device 
table 450. Thus, the appropriate device walk subroutine, 
as indicated by the entry in the column of the device ta- 
ble 450 corresponding to the wa/fcoperation, is executed 
during step 1315. An illustrative device walk subroutine 
1400 is discussed below in conjunction with FIG. 14. As 
previously indicated, the device walk subroutine 1400 
will determine if the channel representing the indicated 
directory has the file identified by the received pathname 
element and, if successful, will also update the appro- 
priate path structures 1140. 

Thereafter, a test is performed during step 1 320 to 
determine if the device walk subroutine 1400 was suc- 
cessful. In other words, whether the file indicated by the 
name element argument was found in the directory rep- 
resented by the channel argument. If it is determined 
during step 1320 that the device walk subroutine 1400 
was successful, then the current value of the variable, 
channel, is returned, which now points to the file indi- 
cated by the received path name element. 

If, however, it is determined during step 1320 that 
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the device walk subroutine 1 400 was not successful, the 
received channelmay represent a union directory which 
contains the file. Thus, a test is performed during step 
1 325 to determine if the received channel represents a 
union directory. If it is determined during step 1 325 that 
the channel does represent a union directory, then the 
mount union pointer is retrieved from element 635 of the 
received channel, such as the channel 600. As previ- 
ously indicated, when a channel, such as the channel 
600 represents a union directory, the mount union point- 
er 635 will point to a channel representing the current 
directory in the union directory. 

Thereafter, the kernel service device type element 
605 of the channel pointed to by the mount union pointer 
635, such as the channel 600, is evaluated during step 
1 332 to identify the kernel device typeXhaX provides the 
directory, which serves as an index into the device table 
450. Thus, the appropriate device walk subroutine is ex- 
ecuted during step 1 334. A test is performed during step 
.1336 to determine if the device walk subroutine 1400 
executed during step 1334 was successful. In other 
words, whether the file indicated by the name element 
argument was found in the current directory pointed to 
by the mount union pointer 635. If it is determined during 
step 1336 that the device walk subroutine 1400 was suc- 
cessful, then the current value of the variable, channel, 
is returned, which now points to the file indicated by the 
path name element, during step 1350. 

If, however, it is determined during step 1 336 that 
the device walk subroutine 1400 was not successful, 
then other directories, if any, are evaluated. Thus, a test 
is performed during step 1 338 to determine if the current 
channel being evaluated represents the last element in 
the union directory, in other words, whether the pointer 
to the next element of the linked list 880, retrieved from 
element 875 of the mount "to" data structure 850, is null. 

If it is determined during step 1 335 that the current 
channel being evaluated does not represent the last el- 
ement in the union directory, then the value of channel 
is preferably incremented during step 1340 to the chan- 
nel corresponding to the next element in the linked list 
880 which forms the union directory. In addition, the val- 
ue of the pointer 635 in the channel which the union di- 
rectory has been mounted upon is preferably updated 
during step 1342 to indicate the current directory in the 
union pointed to by channel. Thereafter, program control 
will return to step 1332 and continue in the manner de- 
scribed above. 

If, however, it is determined during step 1338 that 
the current channel being evaluated does represent the 
last element in the union directory, then the file indicated 
by the path name argument is not in the channel repre- 
sented by the received channel argument, or in a union 
directory which may have been mounted upon that 
channel Thus, the walk not successful, and the walk 
function 1 300 will preferably return to the calling opera- 
tion during step 1 345, with a value of zero. 

As indicated above, the walk function 1300 will uti- 



lize a device walk subroutine 1400, shown in FIG. 14, 
to determine if a particular directory, identified by a re- 
ceived channel, has an indicated file, identified by a re- 
ceived pathname element In addition, since the re- 

5 ceived channel will point to a new file upon a successful 
walk, the device walk subroutine 1400 will also update 
the appropriate path structures 1140, if necessary. 

As previously indicated, the wa//cfunction 1300 will 
access the device table 450 to execute the particular 

10 device walk subroutine 1 400 that is suitable for the ker- 
nel device which provides the directory. Thus, each de- 
vice walk subroutine 1 400 will contain the specific code 
necessary to implement a walk function for that partic- 
ular kernel device. The device-specific code is not per- 

ts tinent here. Thus, the device walk subroutine 1400, 
shown in FIG. 14, has been generalized to illustrate the 
concepts pertinent to the present invention. 

The device walk subroutine 1 400 is entered at step 
1405, as shown in FIG. 14. Thereafter, the device-spe- 

20 cific code necessary to determine if the directory repre- 
sented by the received c/ianne/argument contains a file 
identified by the received path name element argument 
is executed during step 1 41 0. A test is performed during 
step 1415 to determine if the path name element argu- 

25 ment was found in the indicated directory. If it is deter- 
mined during step 141 5 that the path name element ar- 
gument was not found in the indicated directory, then 
the device walk was not successful, and the device walk 
function 1400 will preferably return to the calling walk 

30 function 1 300 during step 1420, with a value of zero. 

If, however, it is determined during step 1415 that 
the path name element argument was found in the indi- 
cated directory, then the device walk was successful, 
and the appropriate data structures must be updated 

35 during steps 1430 through 1460 to indicate that the re- 
ceived channel now points to the file indicated by the 
received pathname element Thus., the element 615 of 
the received channel is preferably updated during step 
1425 to reflect the qid value of the file identified by the 

40 path name element argument. It is again noted that the 
qid value is provided by the device which provides the 
file, and is obtained during execution of the device-spe- 
cific code during step 1410. 

Now that the received channel points to a new file, 

45 the pointer in the channel that points to the path data 
structure 1140 associated with the file must be updated 
as well. In addition, if the file now pointed to by the re- 
ceived channel has not been previously accessed, then 
a path data structure 1140 will have to be created. 

so As previously indicated, the server tree path list 
1110 contains a list of pointers to all of the path data 
structures associated with device that provides the file. 
The server tree path list 1110 is preferably hashed by 
the pathname element and the pointer to the path data 

55 structure of the parent file. Thus, the appropriate hash 
value is utilized during step 1430 to access the appro- 
priate linked list 1126 of path data structures. A test is 
performed during step 1 435 to determine if a data struc- 
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ture in the linked list 1126 has a filename equal to the 
received pathname element argument and a pointer to 
parent path data structure value, retrieved from element 
1 1 44 of the path data structure 1 1 40, equal to the pointer 
to path structure value indicated in element 640 of the 
received channel argument. 

If it is determined during step 1 435 that a data struc- 
ture in the linked list 1126 does not have a filename 
equal to the received pathname element argument and 
a pointer to parent path data structure value 11 44 equal 
to the pointer to path 640 indicated in the received chan- 
nel, then the current file has not been previously ac- 
cessed, and thus a path data structure has not previ- 
ously been created for the file. 

Thus, a path data structure 1140 is preferably cre- 
ated during step 1 440 for the file with the file name ele- 
ment 1142 populated with the received path name ele- 
ment argument and the pointer 1144 to the parent path 
data structure equal to the received channel argument. 
The path data structure 1140 created during step 1440 
is then inserted in the linked list 1126 of path data struc- 
tures accessed during step 1 430. Step 1 445 may be im- 
plemented, for example, by copying the pointer 1128 to 
the linked list, if any, from the entry in column 1124 of 
the path tree list 1110 into the last element 1148 of the 
data structure 1140 created during step 1440, and then 
copying the pointer to the new created data structure 
into the entry in column 1124 of the server tree path list 
1110 accessed during step 1430 Thereafter, program 
control will proceed to step 1450 and continue in the 
manner described below. 

If, however, it was determined during step 1 435 that 
a data structure in the linked list 1 1 26 does have a filena- 
me equal to the received pathname element argument 
and a pointer 1144 to the parent path data structure 
equal to the received c/Ta/me/argument, then a path da- 
ta structure 1140 has been previously created for the 
file. Thus, the path structure pointer 640 in the received 
channel \s preferably updated during step 1450 to point 
at the path data structure of the file walked to, indicated 
by the received path name element argument. 

The path structure pointer 640 in the received chan- 
ne/now points to the path data structure associated with 
the file walked to, and no longer points to the path data 
structure associated with the file walked from. Thus, the 
reference counter 1146 in the path data structure 1140 
associated with the file walked to is preferably incre- 
mented during step 1455 and the reference counter 
1146 in the path data structure associated with the file 
walked from is preferably decremented during step 
1460. In this manner, a count of the number of pointers 
currently pointing to each structure is maintained. 

Thereafter, program control will preferably return to 
the walk function 1 300 with the current value of the var- 
iable, channel, during step 1475. 

As previously indicated, the kernel 400 includes a 
domount function 1500, illustrated in FIG. 15, which will 
receive a channel argument, and access the mount ta- 



ble 800 to determine whether the channel represented 
by the received channel argument has been mounted 
upon. If the domount function 1500 determines that the 
channel corresponding to the current value of the vari- 

s able channel has been mounted upon, the value of the 
variable channel will be translated to indicate the chan- 
nel which has been mounted. The domount function 
1500 will be entered at step 1505, with a received chan- 
nel as an argument. 

10 The domount function 1500 will preferably retrieve 
the qid value from element 615 of the received channel 
and implement the appropriate hash function on the qid 
value to access the appropriate linked list 826 of mount 
"from" data structures during step 1510. A test is per- 

15 formed during step 1 51 5 to determine if a channel point- 
ed to by a mount "from" data structure has the same qid 
value as the received channel argument. If it is deter- 
mined during step 1515 that a channel pointed to by a 
mount "from" data structure does have the same g/dval- 

20 ue as the received channel argument, then the mount 
"to" pointer 845 is followed to the corresponding mount 
"to" data structure 850 to retrieve the pointer 855 to the 
mounted channel. 

Thus, the channel pointed to by the mount "to" 

2S pointer 855 is cloned during step 1520 and reassigned 
to the variable, channel, during step 1520. It is noted 
that a channel in the mount table 800 is preferably 
cloned before being operating upon, so that the opera- 
tions performed on the cloned channel do not affect the 

30 mount table 800 

If, however, it is determined during step 1515 that 
a channel pointed to by a mount "from" data structure 
830 does not have the same qid value as the received 
channel argument, then the channel has not been 

35 mounted upon, and the channel value can be returned 
during step 1525, unaltered. 

EXPORT PROCESSING TO REMOTE PROCESSOR 

40 As previously indicated, in a distributed system, 
such as the distributed computing environment 100, a 
user may export computation-intensive applications, 
such as compilation, to a remote processor, such as the 
cpu server 120, for example, by executing a cpu com- 

45 mand. After the cpu command is executed by the user, 
a command prompt from a command interpreter will ap- 
pear in the display window of the terminal, such as the 
terminal 105. However, the command interpreter is ex- 
ecuting on the cpu server. 

so As discussed further beiow ; the cpu command will 
induce the terminal to export an accurate description of 
the local name space to the cpu server 120. The cpu 
server 120 will utilize the received name space to as- 
semble a name space substantially identical to the ter- 

55 minal's name space. In this manner, the cpu server 1 20 
will see the same customized view of the distributed sys- 
tem 100 which has been assembled by the terminal. 
In a preferred embodiment, the cpu command will 



a 0738970A1 I > 



19 



37 



EP 0 738 970 A1 



38 



invoke execution of a process execution exporter 1600, 
illustrated in FIG 16A, on the user terminal 105. The 
process execution exporter 1600 will transmit messag- 
es to the selected cpu server 120, which will, in turn, 
invoke execution of a process execution importer 1650, 
illustrated in FIG. 16B, on the selected cpu server 120. 
As discussed below, execution of the process execution 
exporter 1600 and the process execution importer 1650 
requires interaction between the two processes on the 
two remote processors. A convention has been adopted 
in the flow charts of FIGS. 16A and 16B to illustrate the 
transfer of signals between the various computing sys- 
tems When a processor is transmitting a signal to an- 
other processor, the process step is illustrated in a box 
shaped as a right-pointed arrow, such as step 1610 of 
FIG 1 6A. Similarly, when a processor is receiving a sig- 
nal transmitted from another terminal, the process step 
is illustrated in a flag-shaped box, such as step 1660 of 
FIG 16B 

As illustrated in FIG. 16A, the process execution ex- 
porter 1600 will be entered at step 1605, for example, 
upon the execution of a cpu command by the user or a 
process Thereafter, the process execution exporter 
1600 will dial the selected remote processor, such as 
the cpu server 120, during step 1610, in a known man- 
ner. According to a feature of the present invention, an 
accurate representation of the current state of the local 
name space will be generated and transmitted to the se- 
lected cpu server 120 

Thus, a read name space subroutine 1700, dis- 
cussed below in conjunction with FIG. 17, is executed 
during step 1620. As previously indicated, the local 
name space is formed by a series of bind and mount 
commands. Each bind and mount command is imple- 
mented by an entry in the mount table 800. Thus, the 
read name space subroutine 1 700 will access the mount 
table 800 to generate a name space list, comprised of 
the "Irom" and "to" files associated with each bind an6 
mount command, which form the current state ol the lo- 
cal name space. It is noted that the preferred implemen- 
tation of the read name space subroutine 1 700 will gen- 
erate the name space list in terms of pathnames in the 
name space of the server which provides the particular 
file, and not necessarily in the local name space. 

Thus, a pathname substitution subroutine 1800, il- 
lustrated in FIG. 18, is preferably executed during step 
1625 to analyze the name space list returned from the 
read name space subroutine 1700 and to replace the 
"from" and "to" pathnames in the name space of the 
server which provides the particular file, with the com- 
plete pathnames in the overall local name space of the 
process 

It is noted that although the "from* and "to" 
pathnames in the name space list are fully specified in 
the local name space of the user or process, following 
execution of the pathname substitution subroutine 
1800, the entries in the name space list need to be fur- 
ther analyzed to determine whether each entry is asso- 



ciated with a bind or a mo unt command. It is further not- 
ed that when an entry is the result of a mount command, 
the file tree of a non-kernel file system has been mount- 
ed to a file already in the local name space. Thus, a pipe 
5 or a network connection is required to establish the com- 
munication link to the non-kernel file system, as dis- 
cussed above in conjunction with FIG 7. 

Thus, the process execution exporter 1600 will ex- 
ecute a package name space subroutine 1900, illustrat- 
10 ed in FIGS. 19A through 19C, during step 1630 which 
will analyze the entries in the name space list and pack- 
age them up as a list of bind and mount commands for 
transmission to the selected cpu server 120 over the 
network connection which was established during step 
1610. In addition, for each entry in the name space list 
corresponding to a mount command, the package name 
space subroutine 1900 will provide information to the 
cpu server 1 20 on how to access or establish the appro- 
priate communication link to the mounted non-kernel file 
system. 

Thereafter, the name space package list generated 
by the package name space subroutine 1 900 is trans- 
mitted to the selected cpu server 1 20 during step 1635. 
After the terminal has exported the representation of the 
local name space to the cpu server 120, the process 
execution exporter 1600 becomes a file server during 
step 1640 to answer remote procedure call requests 
from the cpu server 120, that are received over the net- 
work connection. Essentially, when the process execu- 
tion exporter 1600 is acting as a file server for the se- 
lected cpu server 120, the process execution exporter 
1600 is a non-kernel file system, such as the non-kernel 
file system 750 shown in FIG. 7, which has been mount- 
ed into the name space of the cpu server 120. 

As previously indicated, when a user desires to ex- 
port a processing task, such as a computation-intensive 
application, to a remote processor, such as the cpu serv- 
er 120, the process execution exporter 1600 executing 
on the user terminal 105 will dial the selected remote 
processor, such as the cpu server 120, during step 
1610. Preferably, the cpu server 120 includes a process 
execution importer 1650, shown in FIG. 16B, which con- 
tains a daemon process to continuously monitor com- 
munications received over the network to listen for in- 
coming connection requests, in a known manner, as il- 
lustrated by step 1660 of FIG. 16B. Upon receipt of the 
connection request from the process execution exporter 
1600 executing on the terminal 105, the cpu server 120 
will preferably create a new process group for the ter- 
minal during step 1 662 to process commands on the ter- 
minal 105. It is noted that a process group is comprised 
of the one or more processes which share the same 
name space. 

Thereafter, the cpu server 120 will wait during step 
1665 for the name space package list transmitted by the 
terminal during step 1635. Upon receipt of the name 
space package list, the process execution importer 
1650 will create a channel, identified by a file descriptor, 
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fd, representing the root directory of the terminal during 
step 1670. The process execution importer 1650 will 
then create a new name space during step 1675 and 
abandon the old name space. 

The channel representing the root directory of the 
terminal 105, created during step 1670, is preferably 
mounted in the new name space of the cpu server 120 
in the position, /mntAerm, which represents a portion of 
the name space allocated to terminals. As discussed 
above in conjunction with FIGS. 4C and 7, the mounting 
of a channel which represents the root directory of a re- 
mote file system preferably causes the mount device 
470 of the cpu server 1 20 to establish a mount point 450 
to represent the communication link to the user terminal. 
Thus, the channel data structure 705, shown in FIG. 7, 
represents the root directory of the terminal 105, while 
the non-kernel file system 750 is the user terminal 105. 

Thereafter, during step 1685, the process execution 
importer 1650 will execute the list of bind and mount 
commands in the name space package list received 
from the terminal during step 1665. The cpu server 1 20 
will utilize the received name space to assemble a name 
space substantially identical to the name space of the 
terminal 1 05. In this manner, the cpu server 1 20 will see 
the same customized view of the distributed system 100 
which has been assembled by the terminal. 

In other words, the process execution importer 
1650 will bind the resources that were in the name space 
of the terminal 1 05 into the same places in the new cpu 
name space, created during step 1675. For example, 
the file /mnt/term/dev/mouse, representing the mouse 
device on the user terminal 105, will be bound onto the 
file /dev/mouse. Thus, subsequent attempts by the cpu 
to access the file /dev/mouse will be translated by the 
mount driver 470 in the cpu server 120 into remote pro- 
cedure call messages sent to the terminal 105. Thus, 
local resources on the terminal 105, such as the mouse 
and the display monitor, become visible to the process- 
es executing on the cpu server 120 at the same place 
in the name space as on the terminal 105. 

Once the name space package received from the 
terminal has been processed by the cpu server, the 
process will start a shell process and begin a command 
interpreter during step 1690. Execution of the process 
execution importer 1 650 will terminate during step 1 695, 
upon the closing of last channel following execution of 
an end of file command by a user. 

As previously indicated, the process execution ex- 
porter 1600 will execute a read name space subroutine 
1700 during step 1620. The read name space subrou- 
tine 1700 will access the mount table 800 to generate a 
name space list, comprised of the "from" and "to" files 
associated with each bind and mount command that has 
been executed to form the current state of the local 
name space. 

As shown in FIG. 17, the read name space subrou- 
tine 1700 will be entered at step 1705. The read name 
space subroutine 1700 will initialize a variable, name 



space list, during step 1710 which will be utilized to store 
the list of pathnames associated with each bind and 
mount command, in order, which represent the current 
state of the name space. 
5 Thereafter, the read name space subroutine 1 700 

will search each of the mount "to" data structures 850 
in the mount table 800 during step 1720 for the data 
structure 850 having the lowest mountidvalue indicated 
in element 860. As previously indicated, the mountidval- 
ue is incremented upon each new entry added to the 
mount table 800, and serves as a time stamp which al- 
lows the mount table entries to be retrieved in the order 
in which they were created. 

The entry in the mount table 800 corresponding to 
the current mountidvalue is then accessed during step 
1730. An entry is preferably created during step 1740 in 
the name space fist for the current entry in the mount 
table 800 with a pointer to the channel mounted upon, 
retrieved from the corresponding mount "from" data 
structure, as well as the pointer to the mounted channel 
and the mount order flag, retrieved from the mount "to" 
data structure. 

Thereafter, a channel-to-pathname convertor 2000, 
discussed below in conjunction with FIG. 20, is sepa- 
rately executed during step 1760 for the channel mount- 
ed upon and the mounted channel to replace each chan- 
nel in the created entry in the name space list with the 
pathnames corresponding to the channels in the name 
space of the server that provides those files. 

A test is performed during step 1770 to determine 
if there are additional entries in the mount table 800 to 
be evaluated. If it is determined during step 1770 that 
there are additional entries in the mount table 800 to be 
evaluated, then a search is performed during step 1780 
for the next lowest mountidvalue. Thereafter, program 
control will return to step 1730 and continue in the man- 
ner described above. 

If, however, it is determined during step 1770 that 
there are no additional entries in the mount table 800 to 
be evaluated, then program control will return during 
step 1790 to the calling process execution exporter 
1600. 

As previously indicated, the process execution ex- 
porter 1600 will execute a pathname substitution sub- 
routine 1800 during step 1625 to analyze the name 
space list created by the read name space subroutine 
1700 and to replace the "from" and "to" pathnames in 
the name space of the respective server with full 
pathnames in the overall local name space of the user 
or process. It is noted that each entry in the name space 
list is comprised of a pair of "from" and "to" pathname 
elements corresponding to the associated bind or mount 
command. 

As shown in FIG. 18, the pathname substitution 
subroutine 1800 will be entered at step 1805. Thereaf- 
ter, a pathname element is retrieved from the name 
space list during step 1 81 0 The entry in the name space 
list, if any, which precedes the current pathname ele- 
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ment is then retrieved during step 1815. 

A test is performed during step 1820 to determine 
if the root of the current pathname element, which typi- 
cally specifies the mount point where the name space 
of a non-kernel file system is mounted, equals the "from" 
pathname element in the current previous entry. If it is 
determined during step 1 820 that the root of the current 
pathname element does equal the "from" pathname el- 
ement in the current previous entry, then the root of the 
current pathname element is replaced during step 1825 
with the corresponding "to" path from the current previ- 
ous entry. 

If, however, it is determined during step 1820 that 
the root of the current pathname element does not equal 
the "from" pathname element in the current previous en- 
try, then a test is performed during step 1830 to deter- 
mine if there are additional previous entries in the name 
space fist to be evaluated for the current pathname el- 
ement. If it is determined during step 1 830 that there are 
additional previous entries to be evaluated for the cur- 
rent pathname element, then the next previous entry will 
be retrieved from the name space list during step 1835. 
Thereafter, program control will return to step 1820 to 
process the next preceding entry in the manner de- 
scribed above. 

If, however, it is determined during step 1830 that 
there are no additional previous entries in the name 
space fist to be evaluated for the current pathname el- 
ement, then a test is performed during step 1840 to de- 
termine if there are additional pathname elements to be 
evaluated in the name space list. If it is determined dur- 
ing step 1840 that there are additional elements to be 
evaluated in the namespace list, then the next element 
is retrieved from the name space list during step 1845. 
Thereafter, program control will return to step 1815 to 
process the next pathname element in the manner de- 
scribed above. 

If, however, it is determined during step 1840 that 
there are no additional elements to be evaluated in the 
name space list, then program control will return the 
modified name space HstXo the calling process execu- 
tion exporter 1600 during step 1850. 

As previously indicated, the process execution ex- 
porter 1 600 will execute a package name space subrou- 
tine 1 900 during step 1 630 to take the name space fist 
and package it up as a list of binds and mounts for trans- 
mission to the remote cpu server. As shown in FIG. 1 9A, 
the package name space subroutine 1900 will be en- 
tered at step 1 904. The package name space subrou- 
tine 1900 will initialize a variable, name space package 
list, during step 1 908 which will store the list of bind and 
mount commands that are to be transmitted to the cpu 
server 120. 

An entry in the name space list is preferably re- 
trieved during step 1 91 2. The "from" pathname element, 
corresponding to the file which has been mounted upon, 
is evaluated during step 1 91 6 to determine if the current 
entry in the name space list is associated with a bind or 



a mount command. It is noted that a bind may be iden- 
tified by verifying that the "from" pathname is not a 
mounted pipe or network connection. It is noted that the 
"from" pathname associated with a mounted pipe or net- 
$ work connection will include a device that provides pipes 
or network connections. If it is determined during step 
1916 that the current entry in the namespace list does 
correspond to a bind, then a bind command is added to 
the name space package list, during step 1920 with the 
10 "from" and "to" pathnames that were retrieved from the 
current entry of the name space list during step 1912. 
Thereafter, program control will proceed to step 1990, 
discussed below. 

If, however, it is determined during step 1916 that 
15 the current entry in the name space list does not corre- 
spond to a bind, then the entry must correspond to a 
mount command, and the "from" pathname represents 
a pipe or a network connection to a non-kernel file sys- 
tem. Thus, a test is performed during step 1924 to de- 
20 termine if the "from" pathname indicates that the current 
entry corresponds to a mounted pipe. It is noted that if 
the "from" pathname does indicate a mounted pipe, the 
pathname will typically include the kernel device that 
provides pipes. It is further noted that a pipe can be a 
25 named pipe, indicated in the /srv directory, as discussed 
above, or an unnamed pipe. 

Thus, if it is determined during step 1924 that the 
"from" pathname indicates that the current entry corre- 
sponds to a mounted pipe, then the qid and type values 
30 are retrieved from the channel corresponding to the 
"from" pathname which has been mounted upon during 
step 1 928 Thereafter, a test is performed during step 
1932 to determine if a file in the /srv directory points to 
a channel having the same qid and type values. If it is 
35 determined during step 1 932 that a file in the /srv direc- 
tory does point to a channel having the same qid and 
type values, then the pipe is a named pipe, and a mount 
command is added to the name space package list dur- 
ing step 1936 indicating the file /mnt/term/srv/filename 
40 should be mounted to the file indicated by the "TO" 
pathname, where filename indicates the file in the /srv 
directory identified during step 1932. In this manner, 
when the cpu server 120 performs the indicated mount 
command, the same pipe on the user terminal 105 will 
45 be utilized to access the non-kernel file system mounted 
through that pipe. 

If, however, it is determined during step 1932 that 
a file in the /srv directory does not point to a channel 
having the same qid and type values, then the pipe is 
50 not a named pipe. Accordingly, a file is preferably cre- 
ated in the /srv directory, under a particular filename, 
during step 1940 (FIG. 19B) to store the pointer to the 
channel which represents the pipe, thereby effectively 
making the pipe a named pipe. It is noted that in the 
55 preferred Plan 9 operating system, by executing an 
open command for the file #Mn, where #M indicates the 
mount device 470 (FIG. 4C) and n is equal to the current 
mounrVd value, the result will be the channel itself which 
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represents the pipe, which may be posted in the created 
file in the /s/v directory. 

Thereafter, a mount command is preferably added 
to the name space package list during step 1948 indi- 
cating that the file /mnt/term/srv/fifename should be s 
mounted to the file indicated by the "TO" pathname, 
where filename indicates the file created during step 
1 940. In this manner, when the cpu server 1 20 performs 
the indicated mount command, the same pipe on the 
user terminal 1 05 will be utilized to access the non-ker- io 
nel file system mounted through that pipe. 

It is noted, however, that attempts to create the file 
during step 1940 may not always be permitted by the 
kernel 400, for example, where the access permissions 
have changed. Thus, a test is preferably performed dur- is 
ing step 1 952 to determine if the attempt to create the 
file during step 1940 led to a kernel error, thereby indi- 
cating that the file was not successfully created. If it is 
determined during step 1 952 that the attempt to create 
the file during step 1940 did not lead to a kernel error, 20 
then the file was successfully created, and program con- 
trol will proceed to step 1990 (FIG. 19A), discussed be- 
low. 

If, however, it is determined during step 1952 that 
the attempt to create the file during step 1940 did lead 25 
to a kernel error, then the file was not successfully cre- 
ated. Accordingly /mnt/term is preferably appended to 
the "from" pathname in the current entry of the name 
space fist during step 1 956 Thereafter, a bind command 
is preferably added to the name space package list dur- 30 
ing step 1960 indicating that the appended "from" 
pathname should be bound to the file indicated by the 
"TO" pathname. In addition, as discussed above in con- 
junction with FIG. 16B, the process execution importer 
1 650 will mount the channel representing the root direc- 35 
tory of the terminal to /mnt/term in the name space of 
the cpu server 120 during step 1680. Thus, when the 
cpu server 1 20 attempts to access the file indicated by 
the unappended "from" pathname, it will be translated 
into an access of the file represented by the appended 40 
"from" pathname, and thus go through the mount point 
associated with /mnt/term, to the user terminal 105. 
Thereafter, program control will proceed to step 1990 
(FIG. 19 A), discussed below. 

As previously indicated, a test is performed during 45 
step 1924 (FIG. 19A) to determine if the "from" 
pathname indicates that the current entry corresponds 
to a mounted pipe. If it is determined during step 1924 
that the "from" pathname does not correspond to a 
mounted pipe, but rather, corresponds to a network con- so 
nection, then program control will proceed to step 1964 
(FIG. 19C). It is noted that if the "from" pathname rep- 
resents a network connection, it will be in the form of / 
net/il/2/data, as discussed above in conjunction with 
FIG. 9B. It is further noted that the remote file in the ss 
same directory stores the network destination address 
corresponding to the network connection. Thus, the 
"from" pathname is translated during step 1 964 from the 



data file to the remote file. It is noted that given the data 
file pathname, the change to the remote file is merely 
lexical. In other words, starting with the network 
pathname, such as /net/il/2/data, beginning at the final 
slash character, /, replace the word "data" with "remote". 

Thereafter, the contents of the remote file are re- 
trieved during step 1968. The network destination ad- 
dress retrieved from the remote file is then converted 
during step 1972 to the corresponding machine name 
and service using the network data base 900, discussed 
above in conjunction with FIG. 9A. Thereafter, a mount 
command is added to the name space package fist dur- 
ing step 1976 instructing the cpu server 120 to mount 
the indicated machinelservice to the file specified by the 
"to" pathname. Thereafter, program control will proceed 
to step 1990 (FIG. 19A), discussed below. 

Once the current entry from the name space fist is 
packaged into the name space package fist t in the man- 
ner just described, a test is performed during step 1990 
to determine if there are additional entries in the name 
space fistlo be packaged. If it is determined during step 
1 990 that there are additional entries in the name space 
fist to be packaged, program control will return to step 
1 91 2 to process the remaining entries in the manner de- 
scribed above. 

If, however, it is determined during step 1990 that 
there are no additional entries in the name space HstXo 
be processed, then program control will return to the 
calling process execution exporter 1600 during step 
1995 

As previously indicated, a path data structure 1140, 
discussed above in conjunction with FIG. 11 , associated 
with each channel, provides path information that allows 
the pathname of the given channel to be generated. 

As indicated above, the read name space subrou- 
tine 1700 will execute a channel-to-pathname convertor 
2000 during step 1760 to replace a given channel with 
the pathname corresponding to the channel in the name 
space of the server that provides the corresponding file. 
As shown in FIG. 20, the channel-to-pathname conver- 
tor 2000 will be entered at step 2005, with a pointer to 
the channel to be analyzed. 

Thereafter, the channel-to-pathname convertor 
2000 will access the channel identified by the received 
pointer during step 2010. The pointer 640 to the path 
structure 1140 is then retrieved from the channel data 
structure, such as the channel 600, during step 2015, 
and the pointer 640 is followed to the associated path 
structure 1140. 

A variable, pathname, is initially set to the file name 
retrieved from element 1142 of the path data structure 
1140 during step 2020. Thereafter, the pointer 1144 to 
the path data structure corresponding to the parent file 
is retrieved during step 2025 and followed to the indicat- 
ed path data structure 1140. A test is performed during 
step 2030 to determine if the pointer to the path structure 
of the parent retrieved during step 2025 equals the 
pointer to the path data structure associated with the 
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root directory indicated in element 1102 of the server 
tree path table 1100, in other words, whether the root 
directory has been reached. 

If it is determined during step 2030 that the pointer 
to the path structure of the parent retrieved during step 
2025 does not equal the pointer to the path data struc- 
ture associated with the root directory, then there are 
additional elements in the current pathname to be ob- 
tained. Thus, the file name indicated in. the path struc- 
ture accessed during step 2025 is appended to the front 
of the variable, pathname, during step 2035, separated 
by the slash character. Thereafter, program control will 
return to step 2025 to process remaining elements in 
the path name in the manner described above. 

If it is determined during step 2030 that the pointer 
to the path structure of the parent retrieved during step 
2025 does equal the pointer to the path data structure 
associated with the root directory, then the path has 
been followed all the way back up to the root directory 
of the respective file server and the slash character, /, 
is appended to the front of the variable, path name, dur- 
ing step 2035. Since all of the elements have been proc- 
essed, program control will return to the calling read 
name space subroutine 1700 during step 2050. 

It is to be understood that the embodiments and var- 
iations shown and described herein are illustrative of the 
principles of this invention only and that various modifi- 
cations may be implemented by those skilled in the art 
without departing from the scope and spirit of the inven- 
tion 



Claims 

1. A method performed by a first processor in a dis- 
tributed computing system for invoking execution of 
a processing task on a remote processor, said 
processing task operating on a first name space as- 
sociated with said first processor, said first name 
space being formed by a plurality of name space 
modification commands, said method comprising 
the steps of: 

establishing a communication link between 
said first processor and said remote processor; 
identifying the plurality of name space modifi- 
cation commands that form said first name 
space, said plurality of identified name space 
modification commands including at least one 
dynamic name space modification command; 
and 

transmitting said plurality of name space mod- 
ification commands to said remote processor 
for execution of said processing task by said 
remote processor on a name space modified in 
accordance with said transmitted plurality of 
name space modification commands. 



2. The method according to claim 1 wherein a trans- 
mitted name space modification command includes 
an identification of the communication link to be uti- 
lized by said remote processor to access a mounted 

s resou rce if said name space modification command 

includes the mounting of a file system of a resource 
in an indicated portion of said first name space. 

3. The method according to claim 2, wherein said 
10 identified communication link is an interprocess 

communication pipe utilized by said first processor 
to communicate with said resource, if said mounted 
file system is provided by a resource on the same 
network node as said first processor. 

15 

4. The method according to claim 2, wherein said 
identified communication link indicates that said re- 
mote processor should establish a network connec- 
tion to said resource, if said mounted file system is 

20 provided by a resource on a different network node 
than said first processor. 

5. The method according to claim 1 , wherein each of 
said name space modification commands are 

25 stored in an entry of a mount table, each of said en- 
tries in said mount table including a value that indi- 
cates the order in which said entry was created, and 
wherein said step of identifying the plurality of name 
space modification commands that form said first 

30 name space retrieves said name space modifica- 

tion commands from said mount table entries in the 
order in which they were executed. 

6. The method according to claim 1 , further including 
35 the step of cooperating with said remote processor 

to process file operation requests received by said 
first processor Irom said remote processor for files 
resident on the same network node as said first 
processor. 

40 

7. A method performed by a remote processor in a dis- 
tributed computing system for executing a process- 
ing task received from a first processor, said 
processing task operating on a first name space as- 

45 sociated with said first processor, said first name 
space being formed by a plurality of name space 
modification commands, said remote processor 
having a second name space, said method com- 
prising the steps of: 

50 

processing a connection request from said first 
processor; 

allocating a process on said remote processor 
to execute said invoked processing task; 
55 receiving from said first processor the plurality 

of name space modification commands that 
form said first name space, said plurality of re- 
ceived name space modification commands in- 
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eluding at least one dynamic name space mod- 
ification command; 

establishing a communication link to said first 
processor; 

mounting said communication link to said first 
processor in a predefined place in said second 
name space; 

executing said plurality of received name space 
modification commands to modify said second 
name space; and 

executing said invoked processing task on said 
modified second name space. 

8. The method according to claim 7, wherein a re- 
ceived name space modification command includes 
an identification of the communication link to be uti- 
lized by said remote processor to access a particu- 
lar mounted resource if the name space modifica- 
tion command includes the mounting of a file sys- 
tem in an indicated portion of said name space. 

9. The method according to claim 8, wherein said 
identified communication link is an interprocess 
communication pipe utilized by said first processor 
to communicate with said resource, if said mounted 
file system is provided by a resource on the same 
network node as said first processor. 

10. The method according to claim 8, wherein said 
identified communication link indicates that said re- 
mote processor should establish a network connec- 
tion to said mounted resource, if said mounted file 
system is provided by a resource on a different net- 
work node than said first processor. 

11. The method according to claim 7, further including 
the step transmitting file operation requests to said 
first processor for files resident on the same net- 
work node as said first processor. 

1 2. An apparatus for storing name space information in 
a node of a distributed computing system com- 
prised of a plurality of resources, each of said re- 
sources being represented as a hierarchical file 
system, said name space comprised of at least one 
of said resource hierarchical file systems joined to 
said name space by one or more name space mod- 
ification commands, said name space being modi- 
fiable on a per process basis, said apparatus com- 
prising: 

a mount table for storing an indication of each 
of said resource hierarchical file systems joined 
to an indicated portion of said name space by 
said name space modification commands; and 
a server tree path table associated with each 
of said hierarchical file systems joined to said 
name space, said server tree path table provid- 



ing path information for each of said files in said 
associated hierarchical file system, said path 
information albwing said file system hierarchy 
to be recreated, said path information for each 
5 of said files including the name of said associ- 

ated file and an indication of the parent file in 
said hierarchy of said associated file. 

13. The apparatus according to claim 1 2, wherein said 
10 mount table includes an entry for each of said name 
space modification commands, each entry in said 
mount table including a value that indicates the or- 
der in which said entry was created. 

15 14. The apparatus according to claim 1 2, wherein said 
mount table includes an entry for each of said name 
space modification commands, each entry in said 
mount table indicating the interpretation of a first file 
in said name space should be translated into a sec- 

20 ond file. 

1 5. The apparatus according to claim 1 2, wherein each 
of said server tree path tables includes at least one 
pointer for accessing a plurality of path data struc- 
2S tures, each of said path data structures being asso- 
ciated with a file in said associated hierarchical file 
system and storing said file name and said parent 
information. 

30 16. A method for identifying a pathname associated 
with a given channel in a distributed computing sys- 
tem, said distributed computing system including a 
plurality of distributed resources, each of said re- 
sources being represented as a hierarchical file 

35 system comprised of one or more files, a collection 
of one or more hierarchical file systems forming a 
name space, each of said hierarchical file systems 
having a root directory, each of said channels rep- 
resenting a given file in said name space, each of 

40 said files having a filename comprised of an alpha- 
numeric label, said pathname identifying said file by 
specifying a path through said hierarchical file sys- 
tem from said root directory to said file, said method 
comprising: 

45 

associating a path data structure with each of 
said channels, said path data structure storing 
the filename of said associated file and a point- 
er to said path data structure associated with a 

so parent file in said name space hierarchy; 

receiving an indication of the channel for which 
the pathname is to be identified; 
identifying the path data structure associated 
with said indicated channel; 

55 retrieving said filename and said pointer to said 

path data structure associated with the parent 
file from said identified path data structure; and 
following said retrieved pointer to said path da- 
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ta structure associated with the parent file and 
repeating said previous step until said root di- 
rectory of said hierarchical file system is 
reached, each of said filenames retrieved from 
said path data structures being appended to the s 
front of said generated pathname associated 
with said indicated channel. 
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